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Just because 
you're short of space, 
^ you shouldn't be 
W' short on features 


The ICS-572 2-channel PMC module may be designed specifically for today's small-form 
factor, lightweight PCI systems, but that doesn't mean it compromises on functionality. 

Combining the best in 14-bit ADC and DAC technologies with a high-density, high-speed, user- 
programmable FPGA, the ICS-572 delivers industry-leading cost, size and performance. It's ideally 
suited for multimission, high bandwidth radar and communications applications that need to both 
transmit and receive. 

With support for Windows, Linux and VxWorks, and comprehensive application development support from 
ICS, the ICS-572 offers unparalleled flexibility and speed of deployment. As they say: small is beautiful. 


ICS-572. Great leaps forward. 



ICS 

SENSOR PROCESSING 


RSC# 3 @www.mil-embedded.com/rsc 


CHECK THE FULL SPEC NOW AT 

OR CALL TOLL FREE (US ONLY) 

www.ics-ltd.com/572 

800-267-9794 or 613-749-9241 






VOLUME 1 NUMBER 2 
OCTOBER 2005 


Military 

EMBEDDED SYSTEMS f 


DEPARTMENTS 



Published by: O 0penSystelns 
P Publishing™ 

©2005 Military Embedded Systems 

4 / October 2005 MILITARY EMBEDDED SYSTEMS 


FEATURES _ 

HARDWARE: 

20 Why convert to a SAASM-based GPS? 

By Ron Holm, Symmetricom 

25 Enabling military design security with high-performance 
FPGAs 

By Joel Seely & Jie Feng, Altera 

SOFTWARE: Software Defined Radio 
28 Software communication architecture: Evolution and sta¬ 
tus update 

By Jeff Smith, Ph.D., David Murotake, Ph.D., 
and Antonio Martin, SCA Technica 

34 Cognitive radios: The future of SDR technology 

By Bruce Fette, Ph.D., General Dynamics C4 Systems 

38 Mapping waveforms to systems: What would a wideband 
networking waveform system require? 

By Kevin Maier, Spectrum Signal Processing 

APPLICATION: Performance enhancements 
42 FPGA memory controllers improve DSP performance 

By Richard M. Matthews, Micro Memory 

46 Tapping into solid-state storage benefits for low-power 
and small form factor applications 

By Gary Drossel, Silicon Systems 


E-LETTER _ 

WWW.MIL-EMBEDDED.COM/ELETTER 

Net-centric computing: Architecting a distributed data-management 
infrastructure 

By Bert Farabaugh, RTI 

FLOSS helps you take control of your bytes 

By Robert Dewar, AdaCore 

Please visit us online for the complete list of articles 

Subscribe to the magazine or E-letter: 

www.opensystems-publishing.com/subscriptions 


















"Great in a lab, 
so how about 
in a UAV?" 


RSC# 5 @www.mil-embedded.com/rsc 



Motorola rnskss produces ihnt 
are compile dense and famous 
Tor longevity like V ME bus 
and CompactPCI' boards and 
chassis using various PowerPC* 
and fntel* processors. They Vo 
produced commercially in 
significant volumes, so they'ro 
more competitively priced, How 
do you take full advantage of 
that in a field application? 

COTS by Montorotsi- 
Mods by Arroifli. 

That's where Arrow comes in, 
Wa hava one of Eho broadest 
line cards in the industry and 
the expertise io integrate 
dispa rate s ysfce ms a ha rd wa re, 
and software with extreme 
efficiency. WeVe gotten it right 
for thousands of clients for 
more than 29 years. 

And A rrow team s w i E1 1 
companies like Carlo Gavazzi 
Mupac, recognized across 
the industry for packaging 
and rugged king to meel 
military specs. 

Reliability, Functionality. 
Flexibility, It's like getting full 
customization for a fraction of 
the cost. Yes, That'll fly. 


Q MOTOROLA 

Amhoftad Dis fa ibulor 


OEIV1 Damptiting SaluliDns 
8a£42?r22Se 

wwtlv. arrOwn u cp.c □ m 


Your support system- 









OpenSystems Publishing 

Advertising/Business office: 

30233 Jefferson Avenue 

St. Clair Shores, Ml 48082 

Tel: 586-415-6500 Fax: 586-415-4882 


BUSINESS OFFICE: 

Vice President Marketing & Sales 
Patrick Hopper 

phopper@opensystems-publishing.com 

Business Manager 
Karen Layman 


ADVERTISING GROUP: 

Vice President Marketing & Sales 
Patrick Hopper 

phopper@opensystems-publishing.com 

Senior Account Manager 
Dennis Doyle 

ddoyle@opensystems-publishing.com 

Account Manager 
Tom Varcie 

tvarcie@opensystems-publishing.com 

Print and Online Marketing Specialist 
Christine Long 

clong@opensystems-publishing.com 

Advertising/Marketing Coordinator 
Andrea Stabile 

astabile@opensystems-publishing.com 

European Bureau Chief 
Stefan Baginski 

sbaginski@opensystems-publishing.com 

Account Manager 
Doug Cordier 

dcordier@opensystems-publishing.com 


COMMUNICATIONS GROUP: 

Patrick Hopper 

phopper@opensystems-publishing.com 
Christine Long 

clong@opensystems-publishing.com 


EMBEDDED GROUP: 

Dennis Doyle 

ddoyle@opensystems-publishing.com 
Doug Cordier 

dcordier@opensystems-publishing.com 


MILITARY GROUP: 

Tom Varcie 

tvarcie@opensystems-publishing.com 
Andrea Stabile 

astabile@opensystems-publishing.com 


INTERNATIONAL SALES: 

Stefan Baginski 

sbaginski@opensystems-publishing.com 


For reprints and PDFs call the sales office: 586-415-6500 



Editorial Director Jerry Gipper 
Editorial Director Don Dingee 
Associate Editor Jennifer Hesse 
Senior Editor (articles) Terri Thorson 
Technical Editor Chad Lumsden 
Special Projects Editor Bob Stasonis 
European Representative Hermann Strass 

Canada return address: WDS, Station A, PO Box 54, Windsor, ON N9A 615 

Military Embedded Systems is published six times a year by OpenSystems 
Publishing LLC., 30233 Jefferson Ave., St. Clair Shores, Ml 48082. Subscriptions 
are free, upon request in writing, to persons dealing with or considering 
Military Embedded Systems. 

For others inside the US and Canada, subscriptions are $34/year. For 1st class 
delivery outside the US and Canada, subscriptions are $60/year (advance 
payment in US funds required). 

POSTMASTER: Send address changes to Military Embedded Systems 
16872 E. Ave of the Fountains, Ste 203, Fountain Hills, AZ 85268 


6 / October 2005 MILITARY EMBEDDED SYSTEMS 















Built 

and Tested by Aitech. 



Designing and building board level products and sub-systems for space applications 
is tough enough. Doing it in a true COTS environment is even tougher. It takes a very 
special company to do it right-and that company is Aitech. We not only designed 
and built the world's first harsh environment, open architecture VMEbus boards more 
than two decades ago, but we re f ully qualified for use in today's most hostile 
environment-space. 


The only COTS company... Aitech is the only COTS company in the world that offers embedded 
products for space applications with this combination of features: ■ Designed and qualified specifically 
by us for space 'Radiation-tolerant throughout • On-boa rd triple redun dant memory 'Rad-hard SOI 
(silicon on insulator) ASICs 'Single event effects and total dose radiation survivability 


Total space applicability... Aitech embedded products and sub-systems for space are ideal for Low, Medium and 

High Earth Orbit applications, lunar and Mars robotic vehicles and much more. Our products are used in the Space Shuttle, MIR Space 

Station, international Space Station and other high profile satellite programs where highest performance and reliability are required. 

Heal space-qualified COTS... not custom off-the-shelf...but commercial off-the-shelf. COTS the way it's supposed to be! 

We don't compere with you... some embedded companies try to be systems integrators. We don't. We deliver board-level 
product and integrated sub-systems for space land military/aerospace] applications. We leave the systems integration to the 
companies that do it best... I ike yours! 


We have what you need... from a full range of high performance, low 
cost rad-tolerant, space-qualified CompactFCI SBCs. peripheral I/O boards 
and PMCs, memory boards and enclose res... to complete radiation and 
qual-testing. component obsolescence risk mitigation, lifecycle support 
and program management capabilities - with all the economy-of-scale 
advantages of off-the-shelf products. 

Make us prove it... we can and we will. Call or visit us on the web. 
Embedded space is our space. 



Aitech Defense Systems, Inc. 

9301 Oakdale Avenue 

Chalsworth, CA 91311 

email: sales@rugged.com 

Tull Free: 88B-Aitedi3 - (B83| 248-3243 

Fax; (818) 718-9787 

www.rugged.com 
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- Industry Analysis- 

What has happened to 
product warranties? 

By Jerry Gipper 


M ost embedded electronic 
hardware components come 
with a standard product 
warranty. If a board fails, 
you contact the supplier, arrange a repair 
or exchange, ship it to the repair center, 
and await the repaired or replaced product. 
This is a rather routine process amongst 
all suppliers worldwide. In the case of 
most VME, CompactPCI, and embed¬ 
ded motherboards, today’s warranties 
range from one to three years in duration. 

There used to be a time when warran¬ 
ties from many suppliers were five years 
or in some cases, “lifetime” (Figure 1). 
What ever happened to those warranties? 
Why are they not as common? In the early 
1990s there was a lot of noise in the industry 
about long or lifetime warranties. Press 
releases were distributed touting the war¬ 
ranty terms, and warranties were highlighted 
in advertisements. Suppliers were very 
proud of their product reliability and were 
willing to stand behind their products. 


A quick check today of the same prod¬ 
uct types shows typical warranty periods 
of only two years, with a few as long as 
three years. Certainly these are shorter 
than “lifetime.” Has something happened 
to the reliability? Has the cost of quality 
risen too high to absorb in competitive 
pricing strategies? 

This change in warranty periods started 
quietly happening as companies were 
recovering from the dot-com bust in 2001. 
No embedded technology suppliers pub¬ 
licly “announced” their shorter warranty 
periods. In fact, the reduced warranty 
periods did not hit home until a problem 
occurred and a product needed repair. Did 
suppliers reduce prices to reflect the short¬ 
ened warranty periods? I would venture to 
guess prices were not reduced since sup¬ 
pliers were already under extreme margin 
pressures during those times. 

Some possible explanations exist as to 
why warranties greater than two years are 
no longer typical. Any one or more of the 


Warranty Length 



1980 1985 1990 1995 2000 2005 2010 


Figure 1 



following are key factors in determining 

warranty terms and pricing: 

■ Increased cost of quality: By 
definition, the Cost Of Poor 
Quality (COPQ) consists of costs 
generated as a result of producing 
defective material. Additional cost 
includes all the labor cost, rework 
cost, disposition cost, utilities cost, 
manufacturing cost, and material 
cost that has been added to the unit 
up to the point of rejection. It also 
includes the cost of lost opportunity 
due to the loss of resources used in 
rectifying the defect. The cost of lost 
opportunity means lower revenue 
and profit, potential loss of market 
share, and a lower service level to 
customers. All areas of cost in COPQ 
have increased in past years. 

■ Speed of technology: In general, 
the technologies used in embedded 
computing systems are still relatively 
new. New technologies evolve rapidly, 
and rapidly evolving technologies 
have a shorter product life cycle. 
Getting the quality to an acceptable 
level can be a challenge at best with 
many of the newer technologies. Do 
designers and manufacturers always 
fully understand the quality issues of 
one technology before moving on to 
the next? 

■ Pursuit of quality: With products’ 
shorter life cycles, perhaps the race 
to have the best and most optimized 
set of features at a competitive price 
has pushed quality into the backseat. 
Products today have manufacturing 
lives less than three years in duration. 
In most cases, the quality is not 
fully optimized in that short of a life 
cycle. Suppliers move on to the next 
generation before they really get the 
kinks out of the existing products. 
Sometimes designers may take 
shortcuts or use unproven design 
elements to meet time-to-market 
pressures. With the low quantities 
and high mix of the embedded space, 
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it is hard to spend too much time on 
quality for any single product line. Is 
enough simulation and accelerated 
life testing being done? 

■ Lost the recipe: Perhaps 
manufacturers simply “lost the 
recipe” when changing manufacturing 
locations as mergers occurred or 
manufacturing was transferred 
offshore to large, high-volume 
contract manufacturers to save costs. 
The embedded industry tends to 


build products in small lots with 
a high mix of different types and 
product versions. The manufacturing 
efficiency is never very high in these 
situations. Moving to a high-volume, 
low mix manufacturing facility only 
frustrates the manufacturing process 
in these cases. As a result, quality 
suffers immensely. Lower quality 
levels mean higher warranty costs 
and loss of ability to absorb these 
costs in competitive prices. Most 
manufacturing operations are great at 


building high-quality products, and 
vendors fully understand the nuances 
of quality manufacturing; however, 
it takes high repetitions of the same 
steps and processes to really reach the 
best quality levels. 

■ Service as a profit center: Maybe 
the answer is as simple as using 
warranties as a way to increase the 
revenue stream. Most embedded 
board suppliers have extensive repair 
and service centers. Removing the 
cost of the warranty from the 
product cost and making it a 
separate price line item is a 
way for the service centers to 
improve their revenue streams 
and justify their existence. It 
does make it easier to develop 
custom and innovative service 
programs that better fit the 
customer’s needs. 

What is going to happen to war¬ 
ranty terms in the future? It is 
possible that the Restriction of 
the use of certain Hazardous 
Substances (RoHS) or the Waste 
from Electric and Electronic 
Equipment (WEEE) initiatives 
being driven out of Europe and 
Asia will force further tightening 
of warranty terms. Suppliers may 
use this as the compelling event 
to tighten the warranty programs 
even more. Two-year warranties 
could easily become one-year 
warranties in the next one to 
two years. 

However, all is not lost as many 
suppliers in the embedded 
industry offer various extended 
warranty programs that can be 
customized to meet the specific 
needs of consumers. These pro¬ 
grams have options for warranty 
periods and coverage that can 
help manage costs for the lifetime 
of a program. Extended warran¬ 
ties are insurance against a future 
failure. Be sure to check out all 
your options when planning life¬ 
time costs for your products. 

For more information, you may 
contact Jerry directly at 
jgipper@opensystems- 
publishing.com. 
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Beep, configure, fire 

By Don Dingee 


M ilitary planners are now talking in terms of 
plug-and-fight capability. This is a spin on the old 
personal computing term plug-and-play - catchy, 
but outdated. As a marketing person at heart, I can’t 
help but suggest an updated term that better describes what we 
see taking place and what elements are going into this capability. 

Most of us have seen some version of the movie scene where the 
condemned prisoners are paraded out in blindfolds, lined before 
a wall, and a firing squad is issued the familiar cliche “Ready, 
aim, fire!” 

Today, with electronics driving most combat systems, a more 
appropriate term for the plug-and-fight process would be “Beep, 
configure, fire!” 



and adapt computing hardware to better fit immediate require¬ 
ments. Linux-based open system architectures allow clusters (just 
another term for sy stems-of-systems) to add distributed nodes eas¬ 
ily, enabling distributed processing and sensor fusion capability 
quickly and reliably. 

It’s the intersection of processor, network fabric, and operating 
system in a reconfigurable form that becomes interesting. One 
example of this is the CoSine from Micro Memory. Built on the 
Xilinx Virtex-4 FPGA family with VxWorks running on two 
PowerPC 405 cores, it includes connectivity for serial RapidIO 
or PCI Express, a corner-turning Direct Memory Access (DMA) 
engine to aid in data movement, and a user-programmable area 
for signal processing algorithms. (Refer to the Micro Memory 
article on page 42 in this issue.) 


Beep - Join the network 

For today’s warfighter, there is a wealth of 
information and intelligence available in 
real time as close as the nearest network. 

Sensor and command data fused into the 
network from a variety of modes and loca¬ 
tions enable a tactical system to quickly 
access reliable information on the mission 
plan, threat situation, and the configuration 
of neighboring defense systems. 

Recently, I visited a friend in the San Francisco Bay area, and 
he was showing me his new Bluetooth-enabled phone and head¬ 
set. He commented that he could not help but notice that when 
he wears the headset while driving, especially on the freeways, 
he hears frequent beeps as the headset attempts to connect with 
devices in neighboring vehicles. It’s almost too easy to connect 
to a network now. 

Short-range wireless networks provide a continuous network 
tone and have made it easy to connect quickly to a wide variety of 
devices. Technologies such as Bluetooth, Wi-Fi, Ultrawideband, 
Wireless USB, and the longer-range WiMax may soon be enabled 
with a security layer, enabling their use in defense applications. 
For now, defense networks using Software Defined Radio (SDR) 
technologies fit the bill. 

Planners talk of systems fitting into a netted, distributed force. 
Whether wired or wireless, today’s defense sy stems-of-systems 
are built around network-centric designs and rely on being able 
to join the network quickly. 

Configure - Compute for effect 

Reconfigurable computing has advanced an incredibly long way 
in recent years. Advances in System-on-Chip (SoC) technology 
combining processing with FPGAs allow designers to optimize 


Additionally, advances are being 
made in Linux on FPGA platforms. 
The University of Queensland in Australia 
recently secured a contract for NASA’s 
Reconfigurable Scalable Computing (RSC) 
project, building from a starting point in 
which a version of uClinux is adapted to 
the Xilinx MicroBlaze soft-core proces¬ 
sor. The ultimate goal will be to remotely 
(as in ground-to-space) partially reprogram 
FPGAs on the fly. 

We may see that general-purpose processors ultimately give way 
to reconfigurable processors in defense applications, both for 
functional and life-cycle reasons. Teamed with the University of 
Southern California and using IBM Cu-08 90 nm process tech¬ 
nology, Raytheon’s Morphable Networked Micro-Architecture 
(MONARCH) project targets April 2008 for a device that can 
alternate instantaneously between front-end (streaming) and 
back-end (threaded) processing. 

According to Jack Kelble, president of Raytheon Space and 
Airborne Systems, “In the past, a bank of processor boards 
accepted information and another bank processed it.” He added, 
“Now a tiny but highly sophisticated device a fraction of the size 
will perform both functions with unprecedented speed, power, and 
capacity to store and process a vast amount of data.” MONARCH 
is expected to perform in a single chip or SoC role, possibly sig¬ 
nificantly reducing the number and types of processors required 
for computing systems. In the latter application, it will be 
able to process incoming and outgoing data while analyzing it. 

Fire - With open weapons 

Using technologies such as these, networked, reconfigurable 
weapons systems are beginning to emerge as the norm. Initiatives 
including the Modular Open Systems Approach (MOSA) spon- 


“Today, with electronics driving most 
combat systems, a more appropriate 
term for the plug-and-fight process 
would be ‘Beep, configure, fire!’” 
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sored by The Open Systems Joint Task Force within the US 
Department of Defense continue to set higher expectations. 

Openness in new acquisitions is being demanded as seen in 
these comments from Lieutenant General Ronald E. Keys 
in February 2005: “We’ve got to get to this thing called the 
‘compatible open architecture.’ I’ve got to be able to truly 
plug-and-play, and it’s got to plug-and-play better than Microsoft. 
It’s actually got to plug, boot up, recognize, and work ... So don’t 
bring me stuff that’s not compatible because I’m not going to 
be happy.” 

Large combat systems already architecting around plug-and- 
fight concepts include the Medium Extended Air Defense System 
(MEADS), Future Combat Systems (FCS), and the Littoral 
Combat Ship (LCS). 

MEADS is the US Army’s next-generation replacement for 
Nike Hercules, Hawk, and Patriot air-defense missile systems, 
designed from the ground up to move with ground forces and 
interoperate with other allied forces. It relies heavily on net¬ 
working and distributed intelligence to achieve its mission. 
A MEADS system has the capability to command a fleet of 
distributed missile launchers while simultaneously detecting 
and tracking hostile forces and targets. There is a key tacti¬ 
cal advantage to this distributed design: The missile launch¬ 
ers can be located well away from the ground radar and the 
battle management units, reducing the risk of detection of the 
launchers. This tactical advantage also opens the possibility to 
transfer command and control of the launchers and missiles to 
a neighboring battle management unit, while some management 
systems are offline for whatever reason. 

FCS isn’t a single system but rather a blended system-of-sys- 
tems intended to transform the US Army’s fighting capability. 
Underlying FCS is a software architecture called Fire Control 
- Node Engagement Technology (FC-NET). FC-NET provides 
an adaptable, flexible architecture that modularizes the interac¬ 
tion between the technical weapon system (the intelligence that 
controls and guides the weapon) and the tactical information sys¬ 
tems. This enables weapon systems to readily join the command 
fabric to get the information they require. 

Another plug-and-fight system is LCS. It’s being designed to 
work in three primary mission areas for the US Navy, includ¬ 
ing mine countermeasures, anti-submarine warfare, and 
anti-surface warfare, presumably with anti-air, self-defense 
capability in each role. This is being accomplished through 
the design of mission packages that fit into the sea frame 
and adapt the capability to the desired mission area. Open- 
systems architecture and modular, networked subsystems 
are again the key to success, and the notion of being able to 
reconfigure the system for the role at hand is prominent in the 
architecture. 

Open doesn’t mean big 

Creating new systems-of-systems isn’t necessarily about 
using big computers. From the looks of things, it could be just 
the opposite, using networks of relatively small processors tied 
together wirelessly with very intelligent software and combining 
these systems into larger systems. 


Researchers at the University of Essex are working on a concept 
called the gridswarm, where small Unmanned Aerial Vehicles 
(UAVs) capable of speeds up to 120 mph fly in formations similar 
to the flocking behavior of small birds. In the prototype, these air¬ 
craft are connected by a Bluetooth mesh driven by Linux compute 
modules from Gumstix. These tiny modules run Linux 2.6 on 400 
MHz Intel Xscale processors with 64 MB DRAM and 4 MB Flash, 
along with USB, serial, and optional Bluetooth interfaces. It’s a 
great example of small systems fitting into larger systems fitting 
into still larger systems with aggregated intelligence. 

Rapid developments in wireless networking, reconfigurable 
computing, and network-centric weapons systems are going to 
spawn new innovations quickly. The results should also reduce 
the long-term costs of weapons procurement, enabling easier 
upgrades and reducing the impact of obsolescence by allowing 
subsystem level replacements. 

I’ll be sure to tell my friend the next time I see him that 
when he hears a whole bunch of beeps in rapid succes¬ 
sion on his Bluetooth headset, he should duck. It could 
be a UAV gridswarm reconfiguring just overhead, and hopefully 
they are unarmed and peace loving. 

If you happen to see a gridswarm, or other interesting develop¬ 
ments that beep and configure, drop me a line. 

For more information, contact Don at ddingee@opensystems- 
publishing.com. 
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Trends in military computing 

By Joe Pavlat 



A changing landscape 

These are good times for designers of 
military computer systems, as the range 
of choices and the breadth of applications 
and requirements is greater than ever 
before. Traditionally, military electron¬ 
ics have been extremely expensive, usu¬ 
ally purpose-designed and uniquely built 
for each application. Systems often do 
not communicate with each other, mak¬ 
ing future net centric warfare difficult. 
Reuse of hardware and software has been 
the exception rather than the norm, and 
design cycles historically have been long 
and expensive. Industry insiders often talk 
about the large “flywheel” in the military 
computer business, meaning that devel¬ 
opment cycles are long, and revenues 
are often years away. The one open stan¬ 
dard embraced for military applications, 
the VMEbus, arguably has been widely 
accepted not for its blazing performance 
but rather because the standard was first 
published more than 20 years ago - 
a veritable lifetime for the rest of the 
computer industry. 

The flywheel is still quite large, but it is 
rotating a bit more quickly these days. 
Open industry standards are becom¬ 
ing more popular. Former Secretary 


of Defense William Perry’s famous COTS 
directive was a factor, but the same devel¬ 
opment cost and time-to-deployment 
pressures that affect the commercial com¬ 
puter world affect military suppliers. Two 
PCI Industrial Computer Manufacturers 
Group (PICMG) standards, PICMG 1.0 
(PCI-ISA Passive Backplane, 1994) and 
PICMG 2.0 (CompactPCI, 1995), were 
released 11 and 10 years ago respectively, 
and are used for a variety of military 
applications worldwide. 

A wide range of open 
standards 

PICMG’s first published specification, the 
PCI-ISA Passive Backplane Specification 
released in 1994, is being used in a wide 
range of applications, including the on¬ 
board fire control computer for the Ml09 
Palladin self-propelled howitzer used 
extensively in Operation Iraqi Freedom. 
Companies such as BES Systems Ftd. 
in Israel offer a complete range of rug- 
gedized airborne, vehicle, and naval 
computers compliant to the PICMG 1.1 
specification, additionally providing com¬ 
pliance to military standards including 
MIF-STD-810E, which dictates tough 
requirements for shock, vibration, humid¬ 
ity, fungus, salt and dust, and fog. 


Released in 1995, the CompactPCI 
standard was developed for ruggedized 
industrial applications. It offered then 
state-of-the-art performance, based on 
ubiquitous PCI silicon available from vir¬ 
tually every microprocessor and periph¬ 
eral chip manufacturer. It was based on 
the same IEEE 1101.1 mechanical stan¬ 
dard used by VME, and it became very 
popular for communications applications 
worldwide. Defined for both 3U and 6U 
form factors, the 6U size became popu¬ 
lar for the vast majority of communica¬ 
tions applications, which needed every 
square inch of real estate for components. 
The 3U form factor has historically been 
used largely for instrumentation and some 
industrial automation applications, but 
was not as widely embraced as the larger 
6U form factor. 

This has been changing over the last few 
years in a dramatic fashion. Specially 
ruggedized 3U CompactPCI products are 
being used for a wide variety of airborne, 
vehicle, and even space-based systems. 
One example is the AVC-CPCI 3009 sys¬ 
tem offered by SBS Technologies, devel¬ 
oped for Unmanned Aerial Vehicle (UAV) 
applications (see Figure 1, photo courtesy 
of SBS Technologies, Inc.). Its integrated 
frame grabber and MPEG-4 image com¬ 
pressor connect directly to the airframe’s 
onboard camera, forwarding data in real 
time to war planners on the ground. 

Systems are also going into space. 
Aitech’s S950 3U CompactPCI SBC is 
conduction-cooled and offers a PowerPC 
750FX CPU (see Figure 2, photo cour¬ 
tesy of Aitech Defense Systems, Inc.). 
It is rated to operate in Low Earth 
Orbit, Geosynchronous Orbit, and Mars 
Terrestrial environments. 

The 6U CompactPCI systems are also 
being used for military applications. 
Performance Technologies, Inc. builds 
a sophisticated Mission LAN System 
using the PICMG 2.16 CompactPCI 
Packet Switched Backplane standard. 
Intended to be part of a National 



Figure 1 
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Figure 2 


Command Center aboard a heavily modi¬ 
fied Boeing 707 aircraft known as the 
TACAMO, the system maintains com¬ 
munication and control in the event that 
other command centers are damaged 
or destroyed. It provides networking 
and routing within the aircraft, handling 
packetized radio, satellite, radar, and 
laser transmissions, and ties together 
different systems on the plane (see 
Figure 3, photo courtesy of Performance 
Technologies, Inc.). 

Performance Technologies has also 
developed a unique hybrid CompactPCI/ 


VME system for use in the Global Hawk 
UAV (see Figure 4, photo courtesy of 
Performance Technologies, Inc.). This 
computer provides near real-time high- 
resolution images and intelligence to 
field commanders in theater or across 
the world. Multicast image streams can 
be ordered by a commander in a control 
room or a soldier on the ground in the 
next valley, providing vital current infor¬ 
mation and situational awareness. The 
CompactPCI boards are conduction cooled 
and compliant with the ANSI/VITA 30.1 
specification (2 mm connector practice for 
conduction-cooled Eurocard systems). 


Better architectures hit 
the ground 

One hears a great deal about transforming 
the military from the current platform¬ 
centric approach to network-centric oper¬ 
ations. The underlying computer technol¬ 
ogies, including chips and software, are 
also undergoing fundamental change, and 
it is good news for designers and users of 
military computers. 

Most backplane interconnect technologies, 
including VME and CompactPCI, are 
based on chip-level interconnects that 
were intended for planar motherboards. 
Hot swap was not an integral part of these 
interconnects, and their parallel nature 
has meant that any board plugged into the 
backplane could cause the entire system 
to fail if it failed. Full 2N redundancy was 
often the only solution. Focus was placed 
on reliability instead of the much more use¬ 
ful concept of availability because paral¬ 
lel bus architectures just do not adapt well 
to high availability designs, which require 
system management and failure domains 
of a single board. Also, as core chip 
voltages go ever lower, the notion of 
distributing chip supply voltages often 
means that parallel backplanes are required 
to produce hundreds, or even thousands, 
of amps of current for large systems. 



Figure 3 
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Figure 4 


This is changing for the better. Primarily, 
in order to increase data transfer speed, 
the microprocessor industry is moving 
rapidly towards switched serial inter¬ 
connect technology, popularly known as 
switch fabrics. This technology reduces 
the speed-robbing capacitance typical of 
a parallel bus architecture with instanta¬ 
neous point-to-point interconnects. Not 
only do these interconnects increase data 
transmission speed one or two orders of 
magnitude, which is important for military 
applications such as imaging, they can, 
if properly designed, reduce the fail¬ 
ure domain to a single board or Field 
Replaceable Unit (FRU). They also dra¬ 
matically improve the scalability of mili¬ 
tary systems, as the same packetized data 
format used over the backplane can be 
used between boxes or systems in a large 
network. Switched fabric Ethernet-based 
backplane standards, first introduced to 


the world in 2001 in the PICMG 2.16 
Specification, are beginning to be used 
for military applications. 

Additionally, power distribution concepts 
are changing with an emphasis toward 
shipping higher voltages across back¬ 
planes in order to reduce the ever-increas¬ 
ing currents required by Moore’s Law. 
(We’ll save cooling problems for another 
time.) Localized power conversion is the 
norm in standards like AdvancedTCA 
and PICMG’s recently ratified advanced 
mezzanine card standards. 

An entire book could be written about 
software development, but as much as 
advances in this arena seem to trail hard¬ 
ware progress, a few things can be said. 
Spurred by the wide adoption of the PCI 
bus 10 years ago, military board suppliers 
are increasingly being freed from the need 


to write and maintain cumbersome Board 
Support Packages (BSPs), which often 
need updating every time a chip on the 
board changes revision. The Application 
Programming Interface (API) approach 
moves that responsibility to the chip 
supplier and operating system, making 
systems easier to upgrade and maintain. 
Expensive RTOSs are beginning to give 
way to less expensive and increasingly 
powerful OSs such as Real-Time Linux 
and Carrier-Grade Linux. 

Notions are changing 

In the commercial communications sector, 
the distinction between datacom and tele¬ 
com is all but gone as the world’s infra¬ 
structure moves towards packet-based 
communications. Military infrastructure, 
at least in the US, is joining the movement. 
Major initiatives, such as the Department 
of Defense’s Warfighter Information 
Network Tactical (WIN-T) program, are 
based on commercial communication 
technologies, including secure wireless 
networks, Voice over Internet Protocol 
(VoIP), PCS cellular services, and ATM 
data transport. PDAs, laptops, and tablet 
computers are widely used in American 
command centers worldwide, and e-mail 
is as ubiquitous and important as it is in 
the civilian sector. The old notions about 
ruggedized military computers being 
completely customized boxes milled out 
of large bars of aluminum are changing. 
And they are changing for the better as 
the flywheel spins faster. 

For more information, contact Joe at 
jpavlat@opensystems-publishing.com. 



♦ Dual 10/100/1000 network Ethernet 

♦ Up to 800 MHz FSB supporting 128k 
through 2MB L2 Cache 

♦ PICMG 1.2 with 64 bit/66 MHz support 

♦ Two SATA, One UltraATA/100, Floppy support 

For more information, contact 
a Program Manager at: 

CQStBi 

Hiawatha, Iowa USA 52233-1204 
1.800.378.1636 1.319.378.1636 

www.crystalpc.com 
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Acromag introduces affordable FPGA I/O. For ALL your projects 


A s an engineer, your projects are unique, 
ever-changing, and budget-bound.That's 
why our new PMC modules give you an 
affordable solution to create custom I/O boards. 

But if you thought FPGA computing was only 
for top-end applications, think again. Our 
PMCs are ideal for protocol conversion, 
simulation, in-circuit testing, and much more. 
So why settle for generic I/O when you can 
design exactly what you need while staying in 
budget and reducing your time to market? 

•Virtex®-ll FPGA with 500K, 

2M or 3M system gates 
•1Mb on-chip RAM, 

9Mb on-board SRAM 
• Fast PCI with 32-bit, 

66MHz dual DMA 


Cost-effective custom I/O 

Choose from a variety of I/O configurations: 

• Digital l/0:TTL, RS422,or LVDS I/O 

• Analog I/O:four 20 or 65MHz A/D and two D/A 

Faster time to market 

Why waste precious time building a board from 
scratch? Our new FPGA modules let you process 
your I/O signals any way you want. Quickly. 

Flexibility to meet unexpected challenges 

Acromag FPGA I/O will help you bring your 
projects in on time and under budget. And with 
FPGAs, you'll be ready to adapt 
to all the inevitable changes. 

Thinking about FPGA I/O? 

Think flexible. Think affordable. 
Think Acromag. 



www.acromag.com 
800-881-0268 or 248-624-1541 



Industry Pack FPGA I/O also available 


ANALOG I/O DIGITAL I/O SERIAL I/O FPGA COUNTER/TIMER QUADRATURE 


Manufactured in Wixom, Michigan, USA 
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FPGAs gearing up to dominate 
DSP applications 

By Duncan Young 


AltiVec PowerPCs have enjoyed domi¬ 
nance in high-end military signal pro¬ 
cessing applications such as Software- 
Defined Radio (SDR) and video/image 
compression. But FPGAs, with their 
inherent parallelism and reprogramma¬ 
bility, are fast becoming prevalent and 
easily fit on smaller boards such as PCI 
Mezzanine Cards (PMCs). 

The PowerPC’s AltiVec, 128-bit vector 
processor is the undisputed first choice for 
DSP where floating-point performance is 
the critical decision point. However, the 
new breed of FPGA is geared up to wipe 
out the AltiVec advantage for the great 
variety of the military’s fixed-point DSP 
applications. Interestingly, although the 
AltiVec has been available for some time 
and appears in Freescale Semiconductor’s 
recently announced dual-core MPC8641D 
embedded processor, there does not 
appear to be any interest within the indus¬ 
try in offering competitive (and hence 
better or faster) floating point solutions 
for military DSP applications. 

FPGAs with their innate parallelism 
appear set to oust the traditional multiple- 
PowerPC solution from a broad range 
of DSP applications. FPGAs offer much 
reduced real estate, power consumption, 
and cost. Time-to-deployment pressure 
from end users is driving some COTS 
vendors to offer prepackaged FPGA- 
based hardware/software products for 
specific application segments. 

Let’s talk numbers 

The advent of the latest generation of 
FPGAs such as the Xilinx Virtex-4 or the 
Altera Stratix II — having as many as 
100,000 logic cells, 400 DSP Multiply/ 
Accumulate (MAC) elements and internal 
RAM, clocking at over 450 MHz — offers 
the potential to migrate and integrate DSP 
operations previously only performed by 
dedicated processors. The ability to pro¬ 
cess multiple data streams in parallel sets 
the FPGA solution apart from dedicated 
DSP or PowerPC alternatives. 


Where ultimate performance is required 
on a single channel, the FPGA will always 
lose out. The AltiVec can perform a 
64 x 64 MAC at single instruction rates 
(typically 1.5 GHz), whereas the FPGA 
will achieve 450 MHz for an 18 x 18 MAC. 
The FPGA’s aggregate throughput from 
400 MACs on multiple channels can far 
exceed that of a single PowerPC proces¬ 
sor device in most applications. The DSP 
system designer can now choose from a 
number of design directions: 

Front-end processing of 
multiple array sensors 

Unlike a PowerPC or dedicated DSP 
processor, an FPGA offers many MAC 
elements to perform operations in paral¬ 
lel on incoming data streams. Previously 
this kind of parallelism required many 
PowerPCs to perform repetitive tasks 
such as filtering and decimation from 
each array of the sensor, with the atten¬ 
dant data distribution challenges. This 
data distribution is simple if all the 
PowerPCs are located on, for example, 
just a single VMEbus card, but much 
more complex if they are spread among 
many cards or even racks of cards where 
switched fabrics would be required. Using 
FPGAs can bring about big reductions at 
the critical front end, typically offering 
savings equivalent to one FPGA per lOx 
PowerPCs. Power, weight, space, com¬ 
plexity, and cost are conserved. 

Complete system-on-chip 
fixed-point DSP solutions 

The FPGA provides a versatile set of 
external interface options such as LVDS, 
PCML, LVPECL, and HyperTransport 
with which to build multiple types of 
sensor interfaces. The DSP and logic ele¬ 
ments can be used for filtering and FFT 
operations, plus onboard hard and soft 
processor cores and real-time operating 
systems are available for logical and sys¬ 
tem-level operations. Extensive tool kits 
and libraries are available for the devel¬ 
opment of FPGA architecture, routing, 
and software to suit the final application 
requirement. 



With the notable exceptions of multiple- 
array radar and sonar applications, most 
military applications for DSP are rela¬ 
tively straightforward and can be closely 
coupled to the sensor itself. Typical of this 
class of application are: 

■ Video and image processing 

■ Communications (SDR) 

■ Weapons system sensors such as 
torpedoes, cruise missiles, ground- 
to-air missiles, air-to-air missiles, or 
surveillance UAVs. 

Unlike the multiple-array radar and sonar 
applications that often use many hun¬ 
dreds of PowerPC-class processors plus 
a switched fabric for interconnection, 
these simpler applications listed above 
could be implemented by dedicated DSP 
devices such as the TigerSHARC, ASICs, 
FPGAs, or by a much smaller number of 
PowerPC processors. 

SDR example 

A potential application for a single FPGA 
device could be to form the basis of a 
typical rugged, man-portable SDR with 
multiple secure voice and data chan¬ 
nels. Soft FPGA cores are available for 
filtering, and IFFT/FFT modulation and 
demodulation using the FPGA’s DSP 
elements, plus encryption and decryp¬ 
tion — thus providing a number of com¬ 
munication channels in just one FPGA 
device. To offer complete, system-level 
functionality, this configuration needs to 
be augmented with external interfaces to 
the RF components and the user, plus a 
general-purpose processor for operation 
of the user interface and regular diagnos¬ 
tics/prognostics of the completed system. 
Required user interfaces are: 

■ Serial RS-232/422 channels 

■ Ethernet 

■ USB 

■ Discrete I/O 

An ideal packaging solution for an FPGA 
front-end is the PMC module. Most 
generic SBCs from established military 
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Figure 1 


COTS vendors support the PMC concept 
of I/O, as indeed do many PowerPC- 
based DSP cards. The PMC module is 
independent of the SBC’s processor type 
or bus architecture (for example VMEbus 
or CompactPCI), making it a versatile 
platform for many different applica¬ 
tions. In this example, if the FPGA were 
implemented on a PMC-fomat module, 
it could then be mounted on a COTS 
3U CompactPCI host SBC with either 
a Pentium or PowerPC processor. This 
combination of SBC and PMC would 
form the digital portion of the radio and 
would only occupy a single 0.8" slot 
width, 6.3" deep and 4" high. 


using the FPGA manufacturer’s toolkits. 
Some COTS vendors have taken the idea 
further and developed prepackaged appli¬ 
cations for their FPGA. PMC modules 
that include standard hardware interfaces 
and application-ready code can be used 


In the module’s bundled form, the deliv¬ 
erable product includes all the code 
required for operation out of the box, plus 
physical interfaces to two RS-170 video 
sources and one RS-170 video output. 
Instead of using DSPs or general-purpose 
processors such as AltiVec-equipped 
PowerPCs, the supplied FPGA code com¬ 
presses the two incoming video channels 
using MPEG-4, offering 15 to 20 percent 


DAN BUS INTERFACE TRANSFORMERS 


I | 


SWITCH MODE POWER MAGNETICS 


Premier Magnetics is your source for MIL-STD-1553 databus interface transformers 
for avionics, fly-by-wire and guidance systems. And we’re your source for switch mode power 
supply components-high-frequency transformers, inductors and filter components-complete 
with fully-tested reference designs. 


in areas such as SDR and video compres¬ 
sion-based surveillance. Bundled COTS 
products reduce time-to-deployment to 
satisfy new expectations. 

The TS-MPEG-4 bundled product from 
SBS Technologies shown in Figure 1 
illustrates this product packaging strat¬ 
egy. It is based on a standard air- or con¬ 
duction-cooled PMC module with an 
Altera Stratix EP1S30 FPGA, 128 MB of 
SDRAM, and a PCI interface to the host 
SBC. This PMC can be used in its basic 
form in many different applications with 
the customer developing code to suit. 
The external interfaces can be tailored 
by means of a unique micro-mezzanine 
mounted on the PMC module itself. 


Time-to-deployment of new 
FPGA designs 

Time-to-deployment of new technology 
has become a critical factor in the mili¬ 
tary procurement process. Whereas proj¬ 
ects would once take many years to reach 
combat status, with what was by then 
obsolete technology, timescales have 
shrunk. Introducing new capabilities such 
as security and surveillance now demands 
not just the latest technology but all the 
tools and application support required for 
their immediate use. 

Though SOC FPGAs promise the benefits 
of technology leadership, there is con¬ 
siderable development effort required to 
reach deployment when undertaking new 
application designs. This requirement 
is so even if it is based on a typical off- 
the-shelf solution such as a PMC module 


Smallest Industry Package Sizes 
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Prompt Delivery 


Free Samples 
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better compression ratios than the widely 
used MPEG-2 standard. The card then 
streams compressed data over the PCI bus 
to the host SBC. On the host, the MPEG- 
4 stream is encapsulated and passed to a 
network connection using UDP. Remote 
display clients supplied with the bundle 
can then decompress and display the 
decoded video streams. It should be noted 
that this is an FPGA-based system, reap¬ 
ing all the benefits of FPGAs that we’ve 
been describing. 

Surveillance UAV example 

Battlefield surveillance UAVs such as the 
Altair Predator B variant (Figure 2) are 
good examples of where packaged PMC- 
based FPGAs like the TS-MPEG-4 could 
be used for video capture and compres¬ 
sion. This class of UAV usually flies at 
low to medium altitude over a battlefield 
or other area of particular interest and 
carries a number of video and, possibly, 
high-resolution single-shot cameras for a 
more detailed view of individual objects. 
The UAV will be controlled from a ground 
station that receives images from various 
cameras and displays them for analysis 
by the ground crew. The images may 
then also be relayed further up the com¬ 
mand chain to build a complete tactical 


picture of the battlefield. The downlink 
from the UAV to the ground does not have 
the bandwidth to transmit all the video 
streams directly from the cameras in real 
time, driving the need for compression. 

The mission computer for such a UAV 
is likely to be implemented using COTS 
VMEbus or CompactPCI modules. 
Because of the limited space, weight, 
and power budgets available in a UAV, 
3U CompactPCI would again be an ideal 
format choice for the mission computer. 
FPGA-based PMC modules for video 
compression could be mounted on a host 
SBC or could occupy 3U slots using car¬ 
rier cards. Video streams direct from 
the cameras in RS-170 format would be 
converted to MPEG-4 by the FPGAs, 
then encapsulated and downlinked by the 
mission computer for any of the ground- 
based operations required. 

The FPGA with its unique and flexible 
architecture looks set to replace many of 
today’s dedicated DSP solutions where 
its parallelism and aggregate throughput 
make possible big reductions in real estate 
and cost. Equally, the cost of time-to- 
deployment is becoming a critical factor 
for both the government and system inte¬ 


grator, and FPGA-based solutions often 
provide benefits as well. The availability 
of bundled, application-oriented COTS 
solutions, even though they may require 
minor customization for a particular end- 
use, promise to bring new FPGA-based 
DSP systems online faster and at lower 
cost. 

Duncan Young has worked in the 
defense industry for almost 40 years. 
Duncan was part of the management 
buyout team that formed Radstone 
Technology, and he initiated product 
development of conduction-cooled 
VMEbus modules. He has also served on 
a number of standardization committees. 
Duncan is now an independent 
consultant and writes this column on 
behalf of SBS Technologies. 

For more information, contact: 

SBS Technologies 

2400 Fouisiana Blvd. NE, Ste. 5-600 

Albuquerque, NM 87110 

Tel: 505-875-0600 

Website: www.sbs.com 



18 / October 2005 MILITARY EMBEDDED SYSTEMS 











When failure is not an option . 



Vibration issues? 

We have the answer: 

At 921 mph every part of the F-22 is put to 
the ultimate vibration test. 

Every electrical connection has to work perfectly... 
the pilot is betting his life on it. 


Ruggedized 
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Connectors 

Where reliablity 
and speed of 
data transfer 
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All Hypertronics products are built upon the legendary 
Eiypertac® Contact which outperforms other interconnect options. 

• Immunity to shock and vibration. 

• Up to 100,000 mating cycles. 

• Nearly half the resistance of conventional contact designs. 

• Extremely low insertion and extraction forces. 
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ISO 9001, 13485, & 14001 certified Hudson, MA 1-888-HYPERTAC www.hypertronics.com 
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Visit Hypertronics at MEECC - May 16th & 17th - Long Beach, CA - www.meecc.com 
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Why convert to a SAASM-based 
Global Positioning System? 

By Ron Holm 


In 1998, the Joint Chiefs of Staff 
selected the Selective Availability 
Anti-Spoofing Module (SAASM) as the 
security architecture to bring the Global 
Positioning System (GPS) to the next 
level, and issued the following 
mandate: As of October 1, 2006, all 
newly fielded Department of Defense 
(DoD) GPS systems will use SAASM - 
compliant Precise Positioning System 
(PPS) devices. Procurement ofnon- 
SAASM GPS user-equipment will be 
disallowed unless waived. 

Despite a government mandate requiring 
all newly fielded DoD GPS systems to 
use SAASM-compliant PPS devices by 
October 2006, many military groups and 
other federal agencies continue to pur¬ 
chase receivers without SAASM compli¬ 
ance. Military users purchasing a GPS 
receiver without SAASM, or anyone who 
waits until the October 2006 deadline, is 
taking a security risk. Standard GPS ser¬ 
vice could be denied at any time via war¬ 
fare tactics such as jamming or spoofing, 
and if this occurs, GPS receivers without 
SAASM will find it difficult to correct 
the situation quickly because the process 
to acquire SAASM-compliant receivers 
requires significant time for authorization 
and processing. 

We are going to explain what SAASM is all 
about, why it’s important to GPS receiver 
end-users, and why those who deploy non- 
SAASM receivers are putting their orga¬ 
nization at risk right now - even though 
the deadline is less than a year away. 

Sense of urgency 

The need for improving GPS security 
came to the forefront even more this 
past December in an announcement by 
President George W. Bush in which he 
issued the Space-Based Positioning, 
Navigation, and Timing (PNT) policy. The 
PNT policy authorizes the improvement 
of the United States’ capabilities to deny 
hostile use of any space-based positioning, 


navigation, and timing services without 
unduly disrupting civil and commercial 
access. In the policy, the President specif¬ 
ically directed the Secretary of Defense to 
develop and maintain navigation warfare 
capabilities required to effectively utilize 
GPS services in the event of jamming or 
other interference by adversaries. 

This announcement underscores the fact 
that the federal government is increas¬ 
ing the level of urgency to safeguard 
GPS. The pressure for government 
agencies and military units to convert 
to SAASM-compliant GPS receivers 
is bound to also increase dramatically. 
Along with the selection of SAASM by 


the Joint Chiefs, the writing on the wall is 
clear: All defense agencies should begin 
converting to SAASM GPS receivers. 

SAASM explained 

To understand the risks and why it’s 
important to deploy SAASM-compliant 
GPS receivers as soon as possible, a brief 
recap of GPS and SAASM will help. 
GPS has come to play a significant role 
in our everyday tasks during the past 
decade. GPS makes it possible to pin¬ 
point the precise location of any person 
or place, anywhere in the world. It helps 
with everyday things such as how to drive 
our vehicles from Point A to Point B 
via onboard navigation systems. 


Spoofing and encrypted coding 


GPS spoofing involves the intentional sending of a fake GPS signal by a simulated 
satellite mimicking a legitimate GPS satellite. Spoofing produces a false reading in 
GPS SPS devices and, if properly executed, can introduce position and timing errors, 
disrupting navigation and communication systems. 

The low-power GPS satellite transmitters deliver extremely low-strength signals 
(equivalent to 0.0000000000000001 watt) to Earth-based GPS receivers that are vul¬ 
nerable to jamming and spoofing. Jammers are inexpensive, unintelligent electronic 
devices that merely produce a higher-power blocking signal at the GPS frequency. 
Jamming is disruptive but usually detected by the GPS receiver as it stops tracking 
satellites. Spoofing requires more sophisticated, expensive equipment. Spoofing poses 
a particular security risk as it is often undetected by a GPS SPS device. 

The key to preventing spoofing is to deploy 
a GPS receiver that can acquire encrypted 
GPS signals referred to as P(Y) coded signals, 
which are more robust and jam resistant. GPS 
satellites broadcast two signals: a civilian, 
unencrypted signal (referred to as C/A) that 
all GPS receivers can access, and the military 
encrypted coded signal P(Y). GPS devices 
in compliance with SAASM can receive and 
decrypt the P(Y) code (when keyed), which 
authenticates that the signal originated from 
the GPS satellites. The code frequency ranges 
are shown centered about LI in Figure 1. 
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GPS has also become critically important 
to the military to identify the whereabouts 
of friends and foes, and it plays a crucial 
role in the success of military operations 
by providing precise time and frequency 
to communication systems. This allows 
military units to synchronize movements 
and ensure they communicate over secure 
frequency bandwidths that change on 
an irregular basis to avoid detection by 
the enemy. 

Since GPS relies on low-powered fre¬ 
quency waves traveling from satellites to 
GPS receivers on the ground, the technol¬ 
ogy also lends itself to intentional jam¬ 
ming by enemies as well as unintentional 
or intentional jamming by allies. For 
example, the Civil Coarse Acquisition 
(C/A) code signal may be intention¬ 
ally jammed by the US and other allies 
to allow only SAASM and legacy P(Y) 
receivers to access GPS. GPS is also sus¬ 
ceptible to enemy spoofing - the deliber¬ 
ate attempt to mimic a legitimate signal 
and introduce erroneous position and time 
information. 

To combat this situation, the US govern¬ 
ment launched a program in the 1990s 
referred to as SAASM. SAASM deploys 
anti-spoofing measures using cryptogra¬ 
phy to protect authorized users from false 
satellite signals generated by an enemy. 
To understand the reasons for SAASM, 
it helps to have an understanding of the 
components of the GPS system used by 
people, organizations, and governments 
throughout the world. 

GPS mini-history 

Through a satellite navigation system, 
GPS provides positioning and clock 
time to GPS receivers on the earth. 
Conceptualized in 1973, the first GPS sat¬ 
ellite was launched in 1978, and in 1995 
the system became fully operational. 
Today the system consists of 28 satellites 
orbiting 12,500 miles above the Earth. 

GPS was originally intended as a mili¬ 
tary force enhancement system but now 
serves dual purposes: GPS has evolved 
to improve not only military security but 
also the accuracy of the position, velocity, 
and time of any object on earth - securely 
to military users and freely to civil users. 
GPS does this by offering two position¬ 
ing services: Precise Positioning Service 
(PPS) for authorized military users only 
and Standard Positioning Service (SPS) 


for everyone, including the military. SPS 
utilizes a simpler, unprotected C/A code 
that is openly available to commercial, 
civil, and military users. 

The GPS signals are transmitted on two 
L-band frequencies: LI (1575.42 MHz) 
and L2 (1227.60 MHz). The SPS service 
is provided on LI and the PPS service on 
both LI and L2. 


The DoD relies upon GPS as the primary 
source for position, navigation, time, 
and time synchronization. Therefore, the 
GPS network was also built to allow for 
the deployment of security measures. 
Selective Availability (SA) is a security 
technique that involves the introduction 
of intentional errors into the GPS signal, 
which denies full system accuracy to SPS 
users. On 2 May 2000, however, the effects 
of SA were set to zero and it appears 
unlikely SA will ever be set higher. But 
the potential still exists, and this would 
degrade the accuracy of GPS for SPS users. 
Anti-Spoofing (A-S) utilizes cryptography 
and special keys to protect a GPS PPS 
receiver from receiving false satellite 
signals generated by an adversary. 

The SAASM manufacturing and 
integration process 

The detailed regulations that the US gov¬ 
ernment has applied to the SAASM man¬ 
ufacturing process clearly demonstrate 
how serious GPS security has become 
and the need for immediate conversion to 
SAASM-compliant receivers. 


Manufacturers of SAASM GPS receiver 
modules and the products that they are 
integrated into, referred to as PPS Host 
Application Equipment (HAE), must 
work closely with the Key Data Processor 
Loading and Installation Facility (KLIF) 
under strict guidelines. After manufactur¬ 
ing the SAASM unit, the GPS receiver 
manufacturer ships the SAASM hardware 
to the KLIF for the loading of the Key 
Data Processor (KDP) crypto software. 


After return of the SAASM device to the 
manufacturer, production test is com¬ 
pleted and the unit is ready for sale to JPO 
approved customers. 

Figure 1 shows the SAASM GPS receiver 
manufacturing process and integration 
into PPS HAE. 

SAASM receivers support two key types 
to decrypt anti-spoofing and remove 
selective availability: 

Physical-form red keys are classified, and 
distribution is closely protected since red 
keys are unencrypted. 

Newer, black keys, on the other hand, 
are encrypted and unclassified. They 
can be distributed and loaded electroni¬ 
cally, although paper tape distribution 
is still common. The decryption of the 
key only takes place within the secure 
SAASM module. Black keys may be 
renewable in the future via Over-The- 
Air-Rekeying (OTAR). Black keys 
make sense because they solve key dis¬ 
tribution problems and are useless to 



Figure 1 
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the enemy because they are encrypted. 
The DoD recognizes the security, 
delivery, and cost savings associated with 
black keys and wants users to transition 
from red to black keys as soon as possible 
(Figure 2). 

To ensure security of the classified tech¬ 
nology within a SAASM receiver and to 
preclude unauthorized procurement, the 
Navstar GPS Joint Program Office (JPO) 
at the Space and Missile Systems Center 
at Los Angeles AFB ensures compliance 
to DoD security requirements. All devel¬ 
opers, integrators, and users of SAASM 
GPS must be JPO authorized. 

SAASM developers and manufacturers 
must also meet several strict requirements, 
including securing a Communications 
Security (COMSEC) account, a KLIF 
account, and undergoing a complete JPO 
design-review process. Developers and 
manufacturers also have to prove they 
are free of foreign ownership, control, 
and influence and that they have a facility 
security clearance issued by the Defense 
Security Service (DSS). 

Military end-users must receive authori¬ 
zation from the JPO to procure SAASM- 
based devices. When proper authorization 
occurs, the JPO issues a formal letter so 
that authorized manufacturers of SAASM 
GPS receivers will know authorization 
has formally been granted. 


Benefits of SAASM GPS 
receivers 

By purchasing a SAASM receiver now, 
authorized users comply with the DoD GPS 
security architecture and possess the most 
secure GPS technology to enhance their 
ability to use precise positioning, velocity, 
and time in all environments. SAASM- 
based GPS receivers have the capability 
to directly acquire the encrypted, military 
GPS code and no longer have to depend 
on the often-jammed civil GPS code. 

The need for deploying a SAASM receiver 
could become critical at any moment 
since access to the Standard GPS service 
(SPS) could be denied via warfare tac¬ 
tics focused on local and regional denial 
(jamming) of the civil code within an area 
of conflict. In addition to losing access 
to the signal, upgrading GPS SPS based 
systems to SAASM is nontrivial since the 
process to acquire product and distribute 
the keys that can decrypt coded signals 
requires significant time for authorization 
and processing. 

Without a doubt, those military and 
government agencies that wait until the 
SAASM deadline approaches in October 
2006 are taking a security risk. If an enemy 
source attempts to jam or spoof the GPS 
signal, users of non-SAASM receivers 
could lose all of their GPS capabilities. ^ 


Ron Holm is a product 
marketing manager 
for Symmetricom and 
manages the GPS 
Time and Frequency 
Instrumentation prod¬ 
uct line. Ron has been 
involved in the time 
and frequency industry since 1990 and 
has held previous positions in engineer¬ 
ing and engineering management. Ron 
holds a bachelor’s degree in electronic 
engineering from the University of 
Minnesota. 

To learn more, contact Ron at: 

Symmetricom 

2300 Orchard Parkway 

San Jose, CA, 95131 

Tel: 408-964-7619 

E-mail: ttm_sales@symmetricom.com 
Website: www.symmetricom.com 

The views expressed in this article are those of the 
author and do not necessarily reflect the official policy 
or position of the Navstar GPS Joint Program Office, 
the Air Force, the Department of Defense, or the U.S. 
government. 

This article has been modified from the original 
October 2005 version to correct several technical inac¬ 
curacies. - Ed, July 2006. 
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The CMSE is the first and largest International Conference on the use of electronic components 
in military and space systems. This annua! Conference has the highest attendance of engineers, 
project personnel and offers the most technical papers on the following subjects. 


Announcement and Last Call for Papers 

Experts Irom throughout the world are requested to submit a one page abstract* describing the title, scope 
and content of the presentation while emphasizing the key points Papers reporting on actual experience, 
knowledge and data gained from the use of commercial components and COTS in military and space systems 
are solicited Specific subjects for consideration include: 


■ Design Practices 

■ Embedded COTS 

■ Applications 

■ Technology Trends 

■ Case Studies /History 

■ Risk Mitigation 

■ Obsolescence Management 

■ EEE Parts & Components 

■ Radiation Hardness 

■ Selecting COTS and Commercial Suppliers 

■ Reliability Analysis & Testing 


* Abstracts presented for consideration should be submitted before September 20, 2005. 

CMSE 20QG 

Organized by Components Technology Institute, Inc, 

February 6-9, 2006 

For more information on the Conference or Exhibition 

Sheraton Gateway Hotel 

please call 256-535 - f 304 or visit our web site at 

los Angeles, California 

www.cti-us.com 
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Rackmount PPC 
970FX-based HPC 
does 64-bit Linux 


Increasingly, low-cost cluster comput¬ 
ers running open source Linux are being used in semi-benign military environ¬ 
ments. The Mercury XR9 1U server is an example of one of these systems. 
Mercury effectively “bolted” together two PowerPC 970FX-based high-perfor¬ 
mance computing cluster nodes for efficiency and speed. The XR9 runs Terra 
Soft’s 64-bit Linux OS Y-HPC and cluster management suite called Y-lmager. 

The Mercury XR9 contains twin 2.4 GHz CPUs paired up to an IBM CPC925 
Northbridge with a 16-bit 400 MHz HyperTransport cave, providing peer-to- 
peer access between processors, memory, PCI-X bridge, or the Southbridge. 
There are two independent PCI-X buses, three PCI-X slots, and dual Gigabit 
Ethernet ports. There are also four SATA channels, four USB 1.1 ports, and 
dual RS-232 channels. There’s an optional InfiniBand PCI-X HCA with dual 4X 
ports, and an optional serial FPDP PCI-X HCA add-in for dual 2.5 Gbaud ports. 
A separate PowerPC 405EP performs “service and control,” freeing the main 
CPUs for number crunching. 


Mercury Computer Systems 

www.mc.com 
RSC #23086 


Terra Soft Solutions 

www.terrasoftsolutions.com 
RSC #23087 


256-channel 
digital down- 
converter fits 
into Gateflow 
FPGA library 

In order to process wideband radio frequencies in digital systems, Digital 
Downconverters (DDCs) are used once the RF has been converted at the sys¬ 
tem front end. Trouble is, the areas of interest - the channels- have historically 
required lots of DDCs because of low channel density per device. Pentek aims 
to change all that with their Model 4954-430 256-channel narrowband DDC 
intellectual property (IP) core. Designed for use with Xilinx Virtex II, Virtex II 
Pro, or Virtex-4 FPGAs, the company claims this to be “at least an order of 
magnitude” higher channel count than any other implementation available in 
FPGA or ASIC form. 

The high channel-to-FPGA ratio can reduce cost, weight, and space on circuit 
boards and in systems. 16-bit real or complex data can be accepted at up 
to 185 MHz. The architecture utilizes a channelizer stage that generates IK 
fixed adjacent frequency channels with alias-free signals of greater than 75 dB 
across the passband (for each channel). The core includes a 256-channel out¬ 
put switch matrix that gives the user the ability to conduct “coarse tuning” 
between channels. An NCO performs independent tuning on each channel. 
Factory default filter coefficients are available, or users can create their own. 
The Model 4954-430 fits into Pentek’s existing and well-proven Gateflow 
FPGA design kit, which includes cores for data acquisition, FFTs, FIR, radar 
pulse compression, and other general and specific functions. 

Pentek 

www.pentek.com 
RSC #23089 



Hope for “classic” 

DS1691AJ/883 RS-422 drivers 

When was the last time you saw a DIP-packaged 1C? 

If you deal with mil systems, you might’ve been 
working with one of these babies as recently as 
yesterday. That’s because 10+ year military 
life cycles require mature - and sometimes 
obsolete - devices to be sourced for a long, 
long time. We bring this to your attention because QP 
Semiconductor makes a business out of being a “Military Integrated Circuit 
Manufacturer” for QML and older SMD (DESC) devices. It may not be glamor¬ 
ous, but it’s essen/za/to our warfighters. 

The company recently announced redesigned and replacement versions of the 
DS1691AJ/883 RS-422/423 line drivers, which originally came in both MIL- 
STD-883C and DESC 5962-8672101EA versions. Redesigned to match the 
original National Semiconductor 50V bipolar process devices, the replacement 
versions will be marked as QP1691AJ and are expected to be available as form, 
fit, and functional replacements for the originals. QP Semiconductor is perform¬ 
ing a ground-up redesign; initial simulation models have been “successful,” 
and the devices are in layout. Firm delivery dates will shortly be announced. 
The company maintains more than 1,540 ICs in their QML portfolio. 

QP Semiconductor 

www.qpsemi.com 
RSC #23088 




Palm-sized 
vehicle computer 
- small as an 
“ROC” 


It was bound to happen 
- marrying the successful 
stacked concept of PC/104 mod¬ 
ules with conduction cooling 
for harsher environments. Done 
using conduction-cooled PMC and PrPMC modules by COTS supplier SBS 
Technologies, the company’s Rugged Operation Computer (ROC) is designed 
for those tiny available shoehorn spaces found in every system. Weighing just 
six pounds and consuming only 100 in 2 , the ROC is ruggedized for use in UAVs, 
ground vehicles, or even soldier/Marine portable use. SBS is targeting avion¬ 
ics, vetronics, and navtronics applications. 

Available CPU modules include Intel or PowerPC processors on PrPMCs from 
SBS. I/O ranges from the company’s broad line of PMC I/O, plus all industry- 
standard conduction-cooled PMC cards. The ROC accepts an integral 
stacked PMC structure, complete with a 100 W power supply, EMI filter, and 
a CompactFlash disk with up to 128 GB of memory mounted on a PMC carrier 
module. Operating systems range from Windows XP and Linux to INTEGRITY and 
VxWorks. This is one ROC you’ll want to throw at your computing problem. 

SBS Technologies 

www.sbs.com 
RSC #23090 
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Enabling military design security 
with high-performance FPGAs 


By Joel Seely and Jie Feng 



In an era of ever-increasing security 
concerns, SRAM-based FPGAs with a 
built-in configuration bitstream encryp¬ 
tion feature offer critical advantages to 
military systems designers. In addition 
to high density, high performance, low 
development risk, and fast time-to-mar¬ 
ket benefits, they also deliver a secure 
approach for protecting designs against 
copying, reverse engineering, and tam¬ 
pering. For FPGAs without this built-in 
security feature, an additional nonvola¬ 
tile device can be used to protect the 
FPGA design by supplying handshaking 
tokens. 

Military applications are becoming 
increasingly complex. Major programs 
such as Future Combat Systems (FCS) and 
the Joint Tactical Radio System (JTRS) 
are pushing technological capabilities on 
all fronts to their limits. The electronics in 
these systems are relying on programma¬ 
ble logic and FPGAs to provide extreme 
flexibility at a reasonable cost while not 
giving up the requisite computational 
power. For example, secure communica¬ 
tion systems are used to connect a variety 
of airborne, space, ground- and sea-based 
military communication networks. They 
are used in the transmission, processing, 
recording, monitoring, and dissemination 
functions of a variety of such networks, 
including secure data links. All this func¬ 
tionality requires processing power and 
reconfigurability. 

SRAM-based FPGAs provide the highest 
density, performance, and most advanced 
features among all FPGAs, and they are 
reconfigurable. However, SRAM-based 
FPGAs are volatile and require external 
Flash memory or configuration devices to 
store their configuration data. At power- 
up, the configuration data is sent from the 
memory device to the FPGA, which can 
be intercepted. Copying, reverse engi¬ 
neering, and tempering are security con¬ 
cerns for these high-performance FPGAs 
used in military systems. 


Two techniques - configuration bitstream 
encryption and handshaking tokens - can 
be used for securing designs within 
SRAM-based FPGAs. The configuration 
bitstream encryption is enabled using 
Advanced Encryption Standard (AES). 
Handshaking tokens are generated by 
a CPLD after communication with an 
FPGA. The FPGA only operates when 
the handshaking tokens from the CPLD 
match what it generates internally; other¬ 
wise, the design will shut down. 

Let’s investigate these techniques and 
how they secure SRAM-based military 
systems. 

Configuration bitstream 
encryption 

Some of the latest generations of SRAM- 
based FPGAs contain built-in AES 
decryption engines and key storage for 
configuration bitstream encryption. A 
generic flow of secure configuration 
can be carried out in the following three 
steps: 

1. Load the AES decryption key into the 
FPGA. 

2. Encrypt the configuration file with 
the same AES key and store it in 
the external memory, such as a 
configuration or Flash device. 

3. At system power-up, the external 
memory sends the encrypted 
configuration file to the FPGA, which 
then uses the stored key to decrypt 
the configuration file in real time and 
configure itself. 

AES comes in three different key sizes: 
128-bit, 192-bit, and 256-bit. To under¬ 
stand the level of security, studies have 
shown that if one could build a machine 
that could discover a Data Encryption 
Standard (DES) key in seconds, it would 
take that same machine approximately 
149 trillion years to discover a 128-bit 
AES key. (Source: National Institute of 
Standards and Technology) 


Security key storage, which can be in 
either a volatile or nonvolatile location, 
is an important part of overall security. 
When the key is stored in volatile mem¬ 
ory, an external backup battery is required 
when the power is down. Reliability, espe¬ 
cially in military environments, is a major 
concern. Battery life depends on tempera¬ 
ture and moisture levels of the surround¬ 
ing area. If the battery dies, the key will 
be lost, and the device becomes unusable 
and must be sent back to the factory for 
repair. Batteries are often not desirable in 
military applications because of the pos¬ 
sibility of leakage, outgassing, explosion, 
or going dead at an inopportune time. In 
addition, a battery increases overall sys¬ 
tem cost and requires special manufactur¬ 
ing attention. A nonvolatile key, which is 
more reliable, practical, and flexible, can 
be programmed during regular manufac¬ 
turing flow with the FPGA either on- or 
off-board. 

With configuration bitstream encryption, 
only encrypted configuration files and an 
AES key are stored in the system. Even 
if the configuration bitstream is captured, 
it cannot be decrypted without knowing 
the key. There are various ways to hide 
the AES key, including placing it under 
layers of metals in a distributed manner. 
Some FPGA vendors such as Altera also 
utilize additional security techniques to 
make the key difficult to find. Further, 
Altera does not support read back of the 
configuration file, whether it is encrypted 
or not. This adds another layer of security 
to the solution, making it very difficult to 
copy a design. 

Other security breaches 

Reverse engineering any FPGA design 
to a Register Transfer Level (RTL) or 
schematic format through configuration 
bitstream is very difficult and time-con¬ 
suming, even without encryption. For 
high-performance FPGAs, the configu¬ 
ration file contains millions of bits. To 
reveal the mapping from the configuration 
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file to the device resources, one needs to 
reverse engineer the FPGA or the FPGA 
development software. Some FPGA ven¬ 
dors do not disclose the configuration 
file formats, making reverse engineering 
more difficult. With configuration bit- 
stream encryption, one needs to first find 
the key and decrypt the file. It may be 
easier and quicker to build a design from 
scratch than to reverse engineer a secured 
FPGA design. 

Tampering is modifying the design stored 
in the device or replacing it with a dif¬ 
ferent design. The tampered device may 
contain harmful design code capable of 
causing a system to malfunction or steal 
sensitive security data. Tampering can¬ 
not be prevented if a volatile key is used 
because the key is erasable; once the key is 
erased, the device can be configured with 
any configuration file. For the nonvolatile 
key solution, the device can be set to only 
accept configuration files encrypted with 
the stored key. A configuration failure sig¬ 
nals possible tampering with the configu¬ 
ration file during transmission between 
the external memory and the FPGA, or 
during remotely communicated system 
upgrades. This is another advantage of a 
nonvolatile key. 

Handshaking tokens 

Configuration bitstream encryption is only 
available in high-density, high-perfor¬ 
mance SRAM-based FPGAs. The follow¬ 
ing solution allows any FPGA designs to 
remain secure against copying, even if the 
configuration bitstream is captured. This 
is accomplished by disabling the func¬ 
tionality of a user design within the FPGA 
until handshaking tokens are passed to the 
FPGA from a secure external device. The 
secure external device generates continu¬ 
ous handshaking tokens to the FPGA to 
ensure that it continues operation. Figure 1 
compares the software license scheme 
with an FGPA security scheme. 

Configuring the FPGA is similar to 
installing software onto a computer; the 
configuration bitstream is not protected. 
The external secure device is similar to 
the license file. The software will only 
operate when a valid license file is pres¬ 
ent. The user design within the FPGA will 
only operate when the handshaking tokens 
sent from the external secure device are 
valid. A simplified hardware implemen¬ 
tation for this FPGA security solution 
is shown in Figure 2. In this example, a 
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Figure 2 


CPLD is used as the secure external device 
because it is nonvolatile and retains its 
configuration data during power-down. 

After the FPGA is configured, the func¬ 
tionality of the user design within the 
FPGA is disabled because the enable 
signal is not asserted, while the security 
block within the FPGA starts to function. 
The Random Number Generator (RNG) 
generates and sends the initial counter 
value to the CPLD. The CPLD encrypts 
the counter value and sends the resulting 
handshaking token to the FPGA. If the 
handshaking token matches the data gen¬ 
erated inside the FPGA, the enable sig¬ 
nal is asserted and the user design starts 
functioning. This process continues dur¬ 
ing the entire operation of the FPGA. A 
mismatch will cause the enable signal to 
go low and disable the functionality of the 
user design. Figure 3 shows an example 
of how the enable signal is used with a 
simple AND gate. 


The FPGA user design only works when 
the handshaking tokens from the exter¬ 
nal secure device and the data generated 
inside the FPGA are identical. Even if the 
FPGA configuration bitstream is stolen, it 
is useless, similar to software without a 
license. Therefore, the FPGA user design 
is secure from copying. This solution does 
not provide additional protection against 
reverse engineering (though difficult) and 
tampering. 

The security of the solution relies on the 
external secure device being secure and 
the handshaking tokens being unpredict¬ 
able. A secure external device needs to be 
nonvolatile and retain its configuration 
during power-down (for example, CPLDs 
or security processors). The RNG in the 
solution is critical. It ensures that every 
time the device starts up, it uses a differ¬ 
ent initial value. This prevents anyone 
from storing the handshaking tokens in a 
storage device. To prevent someone from 
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detecting the pattern in the handshaking 
tokens, a proven encryption algorithm 
such as AES should be used. 

To ensure that the security scheme works 
properly, the system clock feeding the 
FPGA user design should be the same 
as the system clock feeding the security 
block. This prevents someone from dis¬ 
abling the security block when the enable 
signal is asserted. To further increase 
security, the comparator block can be 
duplicated several times to produce more 
enable signals to feed different portions 
of the user designs, 

Joel Seely has been with 
Altera Corporation for 
five years. Initially in 
charge of the embedded 
applications group, he is 
now technical marketing 
manager for the auto¬ 
motive, industrial, and 
military business unit. 

For more information, contact Joel at: 
Altera Corporation 
101 Innovation Dr. 

San Jose, CA 95134 
Tel: 408-544-8122 
Fax: 408-544-8066 
E-mail: jseely@altera.com 
Website: www.altera.com 
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Tel: 408-544-6753 
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Website: www.altera.com 
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The mast powerful DSP 
to ever hit the screen 


BittWare's new EL! VME/VXS board. 

Ruijgedited. Conduction-Cuuled. COTS Compliant. 

The military has specific needs. BfttWarc has tile solution The new T2-6U-VWE 
board i Vl%). which supports th$ VllA TI YXS> (VME switched serial) standard, is 
the very first COTS VME- based board featuring eigfil ADSP-TS2C1 TrgerSH ARC DSPs 
limn Analog Devices, providing up to 2B.B GFLOPs in a single slat. Designed and 
built tor demanding real time signal processing systems, the T2V6 is particularly 
effective m applications such as sonar, radar imaging and communications. 
Available in both air-cooled and conduction- cuolcd versions, it's ready for Airborne, 
Ground, or Naval environments. The T2V6 is Hie newest member of the Vi Family 
of beards tram BittWare which includes PCI. cPCI. and PMC form-factors. Building 
on BittWare's decade-long expertise in SH ARC-based products, the T2 Family is 
supported by a complete Ime of development software and run time tools. 


What's an yaur screen? 


^BittA 


www.bittii/arB.CD 


TigerSHARC DSP is a registered trademark el Analog Devices, Inc. 
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-SOFTWARE DEFINED RADIO 



Software communication 
architecture: Evolution and 
status update 

By Jeff Smith y Ph.DDavid Murotake, Ph.D., and Antonio Martin 


This article is a “must read” for anyone dealing with the SCA 
or its implementation. It gives a concise status overview , and 
it also identifies ties to other specifications and standards 
bodies such as OMG. - Ed. 


■ Accepts fully programmable traffic and control information 

■ Supports a broad range of frequencies, air interfaces, and 
application software 

■ Supports over-the-air changes of initial configuration and 
waveforms 


Originally developed for the military's Joint Tactical Radio 
System (JTRS) program of Software Defined Radios (SDRs), the 
Software Communications Architecture (SCA) middleware is 
the key component to abstracting the underlying hardware from 
interoperable and programmable waveforms. The SCA, in effect, 
is what reprograms the radios to facilitate their reconfigurabil¬ 
ity. While the SCA remains strongly influenced by the JTRS pro¬ 
gram and the military, it's now also being considered for use in 
commercial and civilian applications. Throughout time, the SCA 
has evolved as users (civilian and military alike), industry com¬ 
mittees, and complementary standards weigh in on SCA features 
and capabilities. 

The SCA is a common specification standard and component-based 
software framework/architecture for SDR. The SCA is designed to 
facilitate waveform portability between different platforms and to 
leverage commercial standards, frameworks, and architectures to 
reduce development cost and improve reuse. Areas addressed by the 
SCA include waveform download, interoperability, operation and 
deployment on SDR devices, APIs (such as network layers, security, 
and common devices), and common component information. 

While there are many interpretations of SDR, for the purposes of 
this article, external devices and the infrastructure composing the 
software bus will not be included as their future is independent of 
the SCA (for instance, they may be addressed by different stan¬ 
dards bodies or deal with hardware migration). Instead, we will 
address the SCA by categorizing it into divisions of infrastructure, 
waveform support, services, device interfaces, heterogeneous pro¬ 
cessor, and security. 

There are many permutations for a future SCA based on antici¬ 
pated and existing commercial and government developments. To 
achieve future goals, it’s key to address the challenges in future 
SCA development, commercialization, and adoption, and to sum¬ 
marize the current state of the SCA and future recommendations. 
Related commercialization and government standardization activ¬ 
ities will certainly also affect the SCA efforts. 

SCA evolution 

SDR has a range of meanings today, depending on the types and 
number of hardware components that are replaced or upgraded by 
software. For simplicity, SDR is a term coined to describe a radio 
with a software-based physical layer that: 


The SCA originated with the JTRS primarily to support SDR 
waveform portability for a new family of SDR tactical radios for the 
US military. The Software Defined Radio Forum (SDRF) assisted 
the JTRS Joint Program Office (JPO) in developing this open frame¬ 
work for SDRs, beginning with version 0.9 to the current version 
3.0 (see jtrs.army.mil/sections/technicalinformation/fset_techni- 
cal_sca.html) with its associated Application Program Interface 
(API), Specialized Hardware and Security Supplements. The 
Specialized Hardware Supplement is the main addition to SCA 3.0, 
which includes other improvements such as the elimination 
of reference counting and security supplement enhancements. 

As the SDRF continues to support development of the SCA, it has 
sponsored the development of both an Open Source Reference 
Implementation (OSRI) for an SCA-compliant Core Framework 
(CF) as well as a compliant waveform based on FM3TR. The 
CF, based on a hybrid Java and C implementation, is available 
to SDRF members. An FM3TR waveform project is expected for 
completion later this year; in addition, the SDRF has developed 
requirements, use cases, Requests For Information (RFI), and 
Requests For Proposal (RFP). Typically, these technical products 
are voted and approved by the SDRF, then transferred via for¬ 
mal liaisons to other organizations such as the JTRS JPO and the 
Object Management Group (OMG), an object-oriented software 
standards organization. 

For the last three years, SCA evolution has taken a parallel com¬ 
mercialization path in the Software Based Communications 
Domain Task Force (sbc.omg.org) within the OMG. In this forum, 
the domain-independent portions of the SCA, the bulk of the SCA, 
such as Lightweight Logging, Lightweight Services, Lightweight 
CORBA Component Model, Smart Antennae API, Digital 
Intermediate Frequency API, Deployment and Configuration of 
Components, and several Security Specifications, are in various 
phases of the standardization process as separate specifications. 
Development of these separate specifications allows commercial 
participation in related tooling and infrastructure. 

Future SCA revisions should decrease in size and complexity as 
these OMG domain-independent specifications are completed 
and used as SCA references. This trend has already begun as the 
Lightweight Logging API was removed from the SCA, referenc¬ 
ing the completed OMG version. 
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The OMG strives for SCA compatibility with its own software 
radio domain-specific version. Synchronization of OMG soft¬ 
ware radio specification improvements with the SCA has been 
achieved through liaisons and OMG member participation in the 
JTRS SCA Technical Advisory Group (TAG) revision process. 

Existing SCA divisions 

To simplify the categorization of changes, the SCA can be thought 
of in terms of current work and divisions as depicted in Figure 1. 
The current SCA 3.0 infrastructure manages the hardware radio 
components deployment by configuring devices and making sure 
they are ready, providing a standard store for configuration files, 
machine state, user attributes, and functional software, and offer¬ 
ing a waveform structure, control, and binding framework for het¬ 
erogeneous processors. 
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Figure 3 

Device APIs, considered peripherals to the SDR, are also pro¬ 
vided as an SCA supplement and at this time, an Antennae API is 
the only such supplement provided. 
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Figure 1 


A standard method to access security functions such as encryp¬ 
tion, authentication, transmission security (TRANSEC), and 
nonrepudiation, is specified in an SCA Security Supplement. 
Because of the nature of this technology, specializations exist for 
each JTRS program. In addition, there exists a parallel Air Force/ 
NSA Multiple Independent Levels of Security (MILS) effort to 
combine the best of FA A DO-178B Common Criteria’s security 
technologies, so as to provision secure services to embedded real¬ 
time, high-assurance platforms. 

Parallel OMG standards plans and initiatives for the security func¬ 
tions and specifications are depicted in the OMG SCA Security 
Roadmap in Figure 2. A Specialized Hardware Specification SCA 
Supplement, available for SCA 3.0, specifies how to improve porta¬ 
bility of software for processing elements other than general-purpose 
processors, including a Hardware Abstraction Layer (HAL) for 
deploying on heterogeneous processors. 


While not specifically addressing a waveform API, the SCA API 
supplement is given to support the portability of applications and 
interchangeability of devices; there is a specialization of the API 
derived from Cluster 1, a large SCA-compliant JTRS program. 
The current SCA assumes services that are provided by CORBA, 
for example, event and time services, and adds a logging service. 


Forecasted SCA divisions 

Using the same divisions previously identified in Figures 1 and 2, 
Figure 3 shows a potential SCA evolution with possible choices. 
SCA changes occur through a Change Proposals (CPs) process 
and are reviewed though a Technical Advisory Group (TAG) and 
Change Control Board process. For instance, SCA 3.1 already 



Figure 2 
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Blade Side- Processing 


Red Side Processing 



Crypto Boundary 


Figure 4 


completed in draft form, includes CP289, detailing a Component 
Portability Specification (note CP289 was not accepted yet). 

At this date, the OMG version of the Software Radio Specification 
is in the Finalization Task Force stage. This specification contains 
only the radio domain and waveform API portions of the specifi¬ 
cation, with the component model separated into different speci¬ 
fications that describe both the Deployment and Configuration 
of Components and Lightweight CORBA Component Model 
currently in the Revision Task Force stage. The SDRF is making 
additional progress with a new Waveform API contracted research 
and development project expected to begin in September, partially 
based on an OMG Software Radio Specification Waveform API 
Subset document. For the present, synchronization of the OMG 
and JTRS versions of the Software Radio specifications has been 
through OMG member participation in the JTRS CP process. 

There are two new device-related specifications in process. The 
first is a Smart Antennae API Specification, with parallel efforts 
in both the SDRF and OMG. The second is an OMG Digital 
Intermediate Frequency (DIF) API Specification providing a stan¬ 
dard API between tuners and the computer(s) hosting the rest of 
the software radio logic. This DIF specification is the software 
analog of the hardware standard driven through the digitalIF.org 
(www.digitalIF.org) standards group. 

As previously mentioned, the OMG Lightweight Logging 
Specification has been finalized, serving as an SC A reference. 
The closest services specification to finalization is the OMG 
Lightweight Services Specification, offering a further reduction 
in SCA complexity. 

The OMG Security Specification roadmap (refer back to Figure 2) 
is still in its initial phases; the first two specifications on this 
roadmap, the Core and Key Management Specifications, are 
in the initial submission stage. The OMG will standardize on 
the black, crypto, and red processing described in Figure 4. 


Common security requirements are combined into this Security 
Subsystem Core to describe the overlap in one specification. The 
Secure Audit and Authentication RFPs are complete, with initial 
submissions in work; the rest of the OMG security submissions 
in Figure 2 will follow. In the meantime: 1) There are JTRS/NSA 
planned upgrades to the SCA Security Supplement; and 2) the 
Joint Program Executive Office (JPEO) is putting together an 
Information Assurance team to plan upcoming security specifica¬ 
tion update and implementation testing. 

Tuning in the future 

If the trend to replace SCA sections with domain-independent 
portions continues, tool vendor support will increase. In addi¬ 
tion, the SCA framework will be smaller, require less testing, and 
eventually support ultra lightweight deployments in small and 
low-power consumption devices. The OMG SWRadio domain- 
specific specification will, in the short term, contribute to the SCA 
though the JTRS SCA change process. The progression from 
SCA 3.0 to SCA 3.1 will support true waveform component por¬ 
tability over heterogeneous processors. 

Commercial SCA adoption is still hampered by many factors such 
as tool and predefined component availability. Future integration of 
SCA and commercial Software Defined basestation specifications 
holds promise as competing commercial standards and the SCA 
improve with liaisons and information sharing between groups.Yj> 
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Cognitive radios: The future of 
SDR technology 

By Dr. Bruce Fette, Ph.D. 


The future of two-way radio communi¬ 
cation lies in the ability to use a single 
device to network with other types of 
devices while intuitively maximizing 
limited bandwidth and harnessing the 
power of flexible and adaptive 
software-based protocols. That future 
- the Cognitive Radio (CR) - is drawing 
closer, thanks to Software-Defined Radio 
(SDR) technology. 

Cognitive radios will learn and autono¬ 
mously perform “cognitive” functions as 
a form of intelligence that comes from 
their ability to be defined and upgraded 
using software. SDR is the foundation 
upon which cognitive radio will be built. 
To understand cognitive radio, we first 
must take a look at SDR. 

The term SDR was originally coined by 
DARPA’s chief scientist, Dr. Joe Mitola, 
who saw a graduation of technologies that 
began with the hardware-defined radio 
and evolved into the digital radio and the 
software-defined radio in which all appli¬ 
cations can be configured by software. 
The Software Defined Radio Forum 
(SDRF) has been working with this technol¬ 
ogy for several years and similarly defines 
SDR as a radio in which the software 
manages and controls the radio’s wave¬ 
form properties and applications. 
Furthermore, an SDR is reprogrammable 
and may be upgraded in the field with 
new capabilities. 

One of the SDRF’s functions is to define 
the standards by which those upgrades 
can be performed so that new technol¬ 
ogy can be harmoniously integrated into 
the radio after it has been fielded with¬ 
out completely replacing all the previous 
hardware functionality. These standards 
will allow equipment developers and, 
eventually, users to enhance the capabili¬ 
ties of their equipment. Because SDRs 
can be upgraded, bugs can be fixed and 
additional functions can be delivered to 
customers, creating incremental value. 


SDR technology standardizes the archi¬ 
tecture and supports a wide variety of 
modulation strategies, access strategies, 
and protocols as well as higher-level 
systems protocols such as trunked radio 
(a system used by local government and 
industry to operate private systems when 
a large number of mobile radios need to 
share frequencies), satellite communica¬ 
tions systems, and even wireless access. 

“[CR] represents an SDR with not 
only the ability to adapt to spectrum 
availability, protocols, and wave¬ 
forms but the capability to learn 
waveforms and protocols, to adapt 
to local spectrum activity, and to 
learn the current needs of its user.” 

The US military has embraced the proper¬ 
ties and characteristics of SDR technology 
by way of the Joint Tactical Radio System 
(JTRS) initiative, which will bring com¬ 
munications interoperability to each of 
the armed services across all of their plat¬ 
forms. JTRS software-defined radios can 
fulfill multiple military communications 
functions and will ultimately be small 
enough to integrate into miniature robotic 
devices or body electronics worn by sol¬ 
diers. Today, some 20,000 SDRs are being 
used by the US military and government 
agencies including the US Navy’s Digital 
Modular Radio (DMR), combat search 
and rescue radios, and specialized radios 
for government agencies in law enforce¬ 
ment and Homeland Security applications. 
SDR technology will improve interoper¬ 
ability among military services, coalition 
partners and public safety officers while 
solving bandwidth problems by reducing 
the number and types of radios required to 
accomplish operational objectives. 

From SDR to CR 

CR builds on SDR technology. It repre¬ 
sents an SDR with not only the ability to 
adapt to spectrum availability, protocols, 
and waveforms but the capability to learn 


waveforms and protocols, to adapt to local 
spectrum activity, and to learn the current 
needs of its user. 

CR technology enables the radio itself to 
learn, allowing it to perform “cognitive” 
functions such as identifying and using 
empty spectrum to communicate more 
efficiently. CRs will sense and adapt their 
behavior according to the environment 
in which they operate. Once there is an 
embedded machine in which the software 
implements the protocols programmed 
for it, the radio is able to be smart and 
alert and it can “negotiate” with its envi¬ 
ronment. For example, a CR would learn 
about various services of interest to its user 
by being aware of its user’s activities. The 
radio knows how to find those services and 
knows the likelihood that some services 
will be of interest to the user in the imme¬ 
diate area. For instance, a CR could be 
aware of a Bluetooth network and what is 
available and of interest to its user within 
the Bluetooth service zone. It could also 
be aware of what’s available in a wireless 
LAN range, cell phone range and so on. 

How does a CR get that smart? The 
defense community refers to a process 
called the OODA Loop - Observe, Orient, 
Decide, and Act. This is similar to the 
process humans perform as they go about 
deciding what to do in a situation. Those 
concepts can be extended to include plan¬ 
ning and learning in the cognition cycle. 
The CR may do many of these kinds of 
things. It may observe and orient itself to 
the spectrum environment and decide and 
act on certain needs and wants of its user. 

Academic research, industrial research, 
and research in the Department of Defense 
will synthesize new protocols, etiquettes, 
and technologies in the form of software 
that’s integrated into the CR. SDRs and 
cognitive radios must use etiquettes to 
know when it’s appropriate to interact and 
how to interact with their environment. 
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Figure 1 shows a representation of what a 
cognitive radio knows: 

■ Where it is 

■ Which services are available - can 
identify and then use empty spectrum 
to communicate more efficiently 

■ Which services interest the user - and 
how to find them 

■ The current degree of needs and 
future likelihood of its user’s needs 

■ How to learn and recognize usage 
patterns 

■ How to apply Model Based 
Reasoning about user needs, local 
content, and environmental context 

Technology drivers and 
infrastructure 

Key embedded technologies essential to 
evolving the SDR into a CR will include 
DSPs that, among other functions, man¬ 
age modulation, cryptography, proto¬ 
cols, and source coding for voice, data, 
and imagery. High-density FPGAs are 
enabling shared, in-system reconfigura¬ 
tion and are the workhorses that change 
waveforms and adjust performance char¬ 
acteristics, frequency, power regulation, 
and other attributes. General Purpose 
Processors (GPPs) must manage more 
complex modem and operating environ¬ 


ment controls that include the Software 
Communications Architecture (SCA), 
CORBA, and Real-Time Operating 
System (RTOS). GPPs will need to have 
significantly increased processing func¬ 
tionality while keeping size and power 
consumption to a minimum. 

As the embedded enabling technologies 
advance core radio functionality, the next 
step in CR will be the application of two 
basic communication “etiquettes”: infra¬ 
structure and spectrum awareness. These 
two etiquettes will determine when it’s 
appropriate to interact and how to inter¬ 
act with the communication environment 
- the “smart” part of the cognitive radio. 

Infrastructure supports the 
radio’s ability to manage pol¬ 
icy, which is the regulatory 
governance (like the FCC) 
that defines user require¬ 
ments pertaining to which 
frequencies are available 
for which purposes, which 
power levels may be used, 
and modulation and access 
permissions. Historically, 
infrastructure has proven 
to be a powerful tool in 
improving communication 


system performance, particularly for 
trunked radios, cellular spectrum bor¬ 
rowing, and demand-defined multiple 
access. For the defense community, the 
most common infrastructure is Demand 
Assigned Multiple Access (DAMA). 
More than 30 years old and fully mature, 
the DAMA system processes and grants 
military communication user requests 
for a certain amount of time and band¬ 
width, thereby enabling a voice, data, 
image, or other communications events. 

Spectrum awareness is based on wave¬ 
form orthogonality, meaning that wave¬ 
forms are intentionally designed to mini¬ 
mize interference between multiple users. 
Waveform differentiation can be found 
in time, frequency, code, modulation, 
and antenna beam-forming techniques. 
Orthogonality is particularly important 
for military applications, such as the 
Navy’s DMR. 

In Figure 2, the DMR can identify a num¬ 
ber of existing signals in the frequency, 
spectrum, space. It identifies the frequency 
and modulation type of the signal and it 
tracks the signal. At the top of the screen 
in the figure, there is a green and red bar. 
The activity levels of the signals from the 
last 10 seconds are measured, providing 
a way to identify an occupied or unoccu¬ 
pied channel. When the user releases the 
channel, it is immediately free for another 
user on the same frequency. It also indi¬ 
cates that new waveforms may occupy 
the open frequency in this spectrum 
space. Orthogonality is particularly 
important considering the number of 
waveforms associated with military and 
coalition communications. 

What CR will do 

To recap, CR infrastructure awareness 
indicates the radio’s ability to operate 



Figure 2 
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according to policy. Spectrum efficiency 
optimizes radio performance by a num¬ 
ber of factors based on orthogonality in 
the dimensions of time, frequency, code, 
or modulation. 

The cognitive radio will also be capable of 
sensing, responding, and determining opti¬ 
mal responses to network and geographic 
operating conditions. Take, for example, 
an ad hoc network, which is a popular and 
pervasive network architecture (Figure 3). 
For an ad hoc network, when node “A” 
wishes to communicate with node “Z 
it doesn’t need to generate a transmit 
signal strong enough to cover the entire 
distance between the two nodes. Rather, 
node “A” sends a signal strong enough to 
communicate to an available node that is 
along the path to “Z”; this reduces power 
and saves energy. By moving along the 
path from open node to open node, the 
information bypasses potential delays 
caused by the transmission “waiting” for 
“busy” nodes to become available. 



Figure 3 

In addition, cognitive radios will be aware 
of subtle nuances within the network’s 
structure such as the physical environment 
that includes data links, transport, and 
management layers. Figure 4 provides an 
example of a protocol stack and illustrates 
the interoperation and bridging of existing 
defense communication networks. 

Geographic awareness is significant, par¬ 
ticularly for international and coalition 
communications. This awareness gener¬ 
ates the radio’s ability to “discern” local 
infrastructure or policy, transmitters and 
receivers, terrain, propagation channels, 
and the location of network members. 
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Figure 4 


As an example, a US Air Force jet is flying 
across European airspace. Each country 
has different communication standards, 
frequencies, and protocols. With a cogni¬ 
tive radio, the flight plan is programmed 
into the radio, and just as GPS tells the 
pilot where they are, the radio would adopt 
the communication architectures of the 
airspace throughout the flight - without 
pilot interface. 

“The cognitive radio will also 
be capable of sensing, responding, 
and determining optimal responses 
to network and geographic 
operating conditions.” 

Another link in the chain of aware¬ 
ness for CR is its ability to understand a 
user’s operating requirements. Through 
software, the cognitive radio could ref¬ 
erence the user’s rank, role, and access 
requirements along with the databases 
and networks needed to complete normal 
operating tasks, thus keeping information 
consistent with the user’s mission. 

Additional cognitive abilities would 
authenticate and certify system access. 
Defined and managed by the user or the 
user’s superiors, it can be accomplished 
over the air. Next, speech and language 
identification can be added. This is a com¬ 
ponent of functional awareness where 
the radio understands the syntactic and 
semantic context of dialog and can switch 
back and forth between text and speech, 
even performing biometrics on the user. 


What’s next? 

Supporting and maintaining the 
communications security policy is also 
critical for the protection of personnel and 
data; it is an integral part of the radio’s 
cognitive functions. Understanding and 
implementing national security policy, 
network operator, hardware/software, 
server authentication policies, stability 
and performance assessments round out 
the majority of a CR’s functions. 

The work of the SDRF, with its associated 
workgroups and committees, will bring 
the technologies and associated poli¬ 
cies necessary for CR to standardization 
and reality. 

Bruce Fette, Ph.D., is 
chief scientist for the 
communication networks 
business area of General 
Dynamics C4 Systems 
in Scottsdale, AZ, and 
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signal processing for telephony and RF 
communications. Fette currently serves as 
the SDRF’s technical chair and is a panelist 
for the IEEE Conference on Acoustics 
Speech and Signal Processing Industrial 
Technology Track. He holds 35 patents 
and has been awarded the Distinguished 
Innovator Award. He received his BS in 
electrical engineering from the University 
of Cincinnati in 1969, his MS in electrical 
engineering from Arizona State University 
in 1974, and his Ph.D. from Arizona State 
University in 1981. 

For more information, visit the General 
Dynamics C4 Systems website at 
www. gdc4 s. com. 
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Mapping waveforms to systems: 
What would a wideband networking 
waveform system require? 

By Kevin Maier 


When building a Joint Tactical Radio System (JTRS) 
modem that must support a wide variety of disparate 
waveforms, it can be very challenging to assess the 
overall system requirements. A pragmatic process exists 
that can be employed to evaluate the requirements of a 
wideband waveform and to map these requirements to a 
hardware platform. 


Our representative waveform would enable end users to exchange 
wideband data on the battlefield or, with systems providing reach- 
back capability such as the WIN-T program, through the Global 
Information Grid (GIG). Other examples of this waveform type 
include the Tactical Data Rate waveform supported by the TRC- 
4000 terminal from Thales, and the AN/GRC-245 HCLOS termi¬ 
nal from Ultra Electronics[l]. 


The steps recommended in this process include: 

1. Creating a representative waveform with the most 
demanding attributes 

2. Performing afunctional analysis of the target radio 
architecture 

3. Mapping the functional analysis to specific processors 

4. Determining the dataflow, bandwidth, and latency 
requirements 

5. Assessing requirements against hardware platforms 

The data presented herein is intended to be instructive in nature 
and is not exhaustive. 

From a functional perspective, most modern tactical military 
waveforms can be classified into three broad representative 
waveform classes that all emphasize different parameters, and 
a rigorous platform evaluation can be done for a representative 
waveform in each class: 

■ Narrowband slow hopping waveforms (< 4k hops per second 
and <1 Mbps data rate) 

■ Narrowband fast hopping waveforms (> 4k hops per second 
and < 1Mbps data rate) 

■ Wideband networking waveforms 

While wideband networking-type waveforms are typically the 
most resource-intensive and demanding of all three classes, in 
reality, the first two classes should also be assessed if the JTRS 
modem is to support them. However, the following platform 
evaluation and information is limited to the examination of a 
representative waveform in the wideband networking class only. 

Step 1: Creating a representative waveform 

A wideband networking waveform may have a broad variety 
of parameters. For instance, the Joint Tactical Radio System 
Wideband Networking Waveform (WNW) has four distinct sig¬ 
nals in space to fulfill its operational requirements: Bandwidth 
Efficient Advanced Modulation, Orthogonal Frequency Division 
Multiplexing, Anti-jam, and Fow Probability of Intercept. For 
this illustration, we will create a waveform representative of the 
most demanding parts of the WNW subcategories. 


Many of the parameters associated with JTRS and other 
waveforms are not publicly available; however, many of these 
waveforms are similar to the IEEE 802 series of networking 
waveforms (802.11, 802.16). As such, we will model the wave¬ 
form based on publicly available information and supplement 
that information with details from 802.x waveforms. This hybrid 
structure will not specifically meet with the requirements of 
either 802.11 or WNW, but will be sufficient to drive the require¬ 
ments of our modem architecture and help to evaluate against 
a hardware platform. The parameters for this representative 
waveform are presented in Table 1. 


Parameter 

Value 

Channel Location in 

Spectrum 

225-2000 MHz 

Channel Spacing 

30 MHz 

Modulation 

OFDM, DQPSK 

INFOSEC 

N/A 

TRANSEC 

None 

Hops Per Second 

None 

OFDM Symbol Length 

80 Samples 

OFDM Guard Interval 

16 Samples 

OFDM FFT Window Length 

64 Samples 

Baseband Sample Rate 

30 Msps 

Error Correction for Payload 

Rate V 2 Turbo Code 

Uncoded data bits per 

OFDM symbol 

48 

Signaling (bps) 

18 M 

Packet Structure 

10 Training Sequence Bursts, 

1 long OFDM Synchronization 
Symbol, 1 SIGNAL Header 
Symbol, 1 to N Data Symbol 

Access Structure 

Carrier Sense Multiple Access 

Acknowledgement Time 

10 ps 

Duplex 

Full 


Table 1 
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Our representative waveform is connection-oriented, meaning 
that for each packet transmitted, an acknowledgement must be 
sent indicating whether the packet was successfully 
received or not. This acknowledgement is based 
on a test of the Cyclic Redundancy Check (CRC) 
embedded in the data. The CRC response must 
be transmitted 10 ps following the receipt of the 
last OFDM symbol, similar to the acknowledge¬ 
ment time for 802.1 lg. A hard requirement such as 
acknowledgement time will help drive the latency 
requirements of our target system. 

Step 2: Performing a functional 
analysis 

After creating a representative waveform, the next 
step in the platform evaluation exercise is to con¬ 
struct a functional block description of the target 
radio architecture. The wideband representative waveform can 
be deployed in a system similar to Figure 1, which shows the 
black side (unclassified) of the modem that partitions the modem 
functionality into six arbitrary blocks: 



Figure 1 


■ RF front end - Provides the antenna interface and first stage 
of down conversion, accepts and distributes IF data to the 
next functional block 

■ IF processing - Performs analog-to-digital conversion and 
up/down conversion of the digital data 

■ Network synchronization and control processing - Converts 
data to/from symbols, contains the Finite State Machine 
(FSM) that controls the radio 

■ Receive channel processing - Performs demodulation, 
deinterleaving and deframing, and FEC decoding 


- Provides higher layer data protocol processing and 
interfaces with the red-side modem processing 
■ Transmit channel processing - Performs modulation, 
interleaving and framing of data, as well as FEC encoding 

In a supporting analysis, the exact data rate, latency, signaling, 
and pin count (where appropriate) are determined for particular 
data flows (indicated by letters) as appropriate to the representa¬ 
tive waveform. A partial analysis of the receive path is shown in 
Table 2. 


(path ID 

Path Description 

Bandwidth, Latency & Determinism Notes 

A 

DDC to Resampler 

The baseband sample rate is 30 Msps, x 2 to allow for synchronization, x 4 bytes per 
sample (1 & Q), which gives a rate of 240 MBps into the resampler 

B 

Resampler to Symbol 

Acquisition & Synchronization 

The resampler will take the data rate down by a factor of 2, to 120 MBps 

C 

Symbol Acquisition to Demod 

Assumption: the training sequence and frequency offset estimation symbols are 
generally irrelevant in the calculation of these rates. 

30 Mbaud x 48/80 (packet overhead factor) x 4 bytes per sample (2 bytes per com¬ 
plex sample) = 72 MBps 

D 

Demod to Deinterleave and 
Deframe 

2 samples per bit and 2 bytes per sample = 36 Mbps 

E 

Deinterleave to Memory 

2 x data rate = 72 MBps assuming 8-bit addressable regions. Could be up to 4x this 
rate if we only have 32 bit addressable regions 

F 

Deinterleave to FEC 

36 Mbps 

G 

FEC to Link Layer Processing 

Rate Y 2 encoding gives 18 Mbps 

H 

DDC RX Control from FSM 

The fine control requires adjustment inside of the guard band of a symbol - or 20% 
of a symbol length = 0.533 pSec 


Table 2 
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Step 3: Mapping to specific processors 

After our representative waveform has been created and mapped 
to a functional block diagram of the modem, the results need to 
be allocated to actual physical processing elements. Notice at this 
point a target platform has still not been identified. The functional 
blocks should be assigned to specific processor types to estimate 
resource utilization that will help determine part sizing, leading 
to appropriate hardware platform architectures. 

In general, high-speed or computationally intensive algorithms are 
mapped to FPGAs, with other algorithms mapped to either a DSP or 
a General Purpose Processor (GPP), depending on the anticipated 
power utilization and requirements for code portability. Higher 
layer back-end processing (link layer, network layer) is typically 
performed exclusively on a GPP. 

In the case of this representative waveform, the functional pro¬ 
cessing blocks described above are mapped into all three differ¬ 
ent categories: DSPs, FPGAs, and GPPs. The functional blocks 
are partitioned as shown in Figure 2. 



Figure 2 


Once the waveform algorithms are partitioned across different 
processors, it is time to start our resource utilization assessment. 
Utilization estimates vary, but significant information is available in 
the public domain (for example, the Xilinx website provides FPGA 
utilization estimates). Much information about MIPS processing 
requirements of waveform components is also publicly available 
from the US government. 


A detailed analysis of each functional processing element must 
be performed to create an accurate resource utilization estimate. 
For instance, our detailed receive side resampler analysis might 
be described as follows: 

Rx resampler: Resampling is required to ensure that 4 samples 
per baud are input to the symbol acquisition and synchronization 
blocks. The resampling architecture follows that of the GC3011A 
resampler. The input rate to this resampler will nominally be 60 
Msps, and the output rate will be 30 Msps. It is anticipated that 
the interpolation filter will be implemented using a Farrow filter, 
following the method prescribed by Harris and Dick[2]. 
This implements a 256-tap interpolation filter as five 8-tap filter 
stages with four MAC stages, thus the equivalent performance for 
the GC3011 is estimated to require sixteen 15-tap filter stages and 
15 MAC stages. The 15-tap FIR filters can be implemented using 
a Distributed Arithmetic (DA) approach with a total estimated 
resource utilization of less than 16 x 125 x 2.25 = 4500 slices[3]. 

Total estimated resource utilization would include 15 multiply 
and add blocks, and 1 block RAM in a Xilinx Virtex-II or Virtex-4 
device. (Note that in Virtex-II, the adder would have to be 
implemented in gates). Also note that since the original filter 
architecture was based on XC4000 series FPGA technology, 
additional savings could be achieved using Virtex-II or Virtex-4 
devices. As such, adding an additional 20 percent logic for over¬ 
head glue logic and allowing for floor planning risk puts total 
FPGA resource utilization at less than 5400 logic cells, 15 multiply 
and accumulate blocks, and 1 block RAM. Other detailed analysis 
leads to the summary presented in Table 3. 

The detailed breakdown in Table 3 leads us to target a platform 
that has a single 600 MHz TMS320C6416 DSP, a GPP capable of 
at least 1000 MIPS, and an FPGA with approximately 32k logic 
cells and 3 x 18k block RAMs. In a size-, weight-, and power-con- 
strained environment such as tactical MILCOM, the target plat¬ 
forms should encompass devices that do not have much excess 
capacity beyond a planned risk margin. For instance, one would 
not employ a Motorola AltiVec engine to field this waveform 
because of the high power consumption and general overcapacity 
of that particular processor. 


Component Name 

Proposed Processing 
Technology 

Estimated Resource Utilization 

Rx Resampler 

FPGA 

5400 Logic Cells, 15 MAC Blocks, 1 Block RAM 

OFDM Symbol Synchronization 

FPGA 

3197 Logic Cells 

OFDM Symbol Acquisition 

FPGA 

1590 Logic Cells, 2 MAC Blocks, 1 Block RAM 

OFDM Symbol to Bit 

FPGA 

10744 Logic Cells 

FSM 

FPGA 

5580 Logic Cells 

Deinterleave/ Decode/ Interleave/ Encode 

TMS320C6416 

<100% 

Link Network Layer Processing 

GPP 

<1000 MIPS 

Symbol Staging 

FPGA 

Minimal 

Tx Resampler 

FPGA 

5400 Logic Cells, 15 MAC Blocks, 1 Block RAM 


Table 3 
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There exist several modern processors that can fulfill the GPP 
requirements for target MIPS and target power consumption; for 
example, 1000 MIPS would require ~80 percent of a MPC 8541 
at 533 MHz and run at approximately four watts. To fulfill the 
FPGA requirements, we could look at the two most recent Xilinx 
FPGA architectures; our waveform would require approximately 
70 percent of a Xilinx Virtex-II Pro V2P40 or 53 percent of a 
Virtex-4 LX60. The Virtex-4 runs at approximately 50 percent of 
the power of a Virtex-II Pro and would be a suitable choice for 
our modem platform. 

Step 4: Determining data flow, bandwidth, 
and latency 

Once the functional blocks have been allocated to individual 
devices, the data flow requirements between our target devices 
can be summarized as shown in Table 4. This analysis will help 
determine if an interprocessor link requires channelized data flow 
and also what amount of bandwidth and latency is required for 
the link. The bracketed letters refer to the data flows identified in 
Figures 1 and 2. 


of hard requirements for a target platform. One can then choose 
to build the hardware from scratch or utilize existing Commercial 
Off-The-Shelf (COTS) boards and modules. The latter option is 
usually desirable if there are schedule or resource limitations. 
A first and easy test to see if specific COTS equipment is suitable 
is to use a checklist approach. Gather product information (typi¬ 
cally available on a datasheet) and compare how well the product 
meets the overall system and data flow requirements. (Note that 
COTS designers marketing tactical MILCOM targeted systems 
should perform the same analysis to ensure that their systems can 
handle the target waveform requirements.) 

The final step in assessing any platform is to actually build a repre¬ 
sentative waveform and port it to the target hardware. An example is 
the recent implementation of the 802.1 lg waveform on Spectrum’s 
off-the-shelf SDR-3000 platform. This waveform requires the same 
bandwidth and latency performance as military wideband wave¬ 
forms and as such demonstrates the SDR-3000’s suitability for 
wideband waveform implementations. 


Step 5: Assessing requirements against 
hardware platforms 

Performing all of the above stages of analysis will generate a set 


Path 

Channels 

Aggregate 

Bandwidth 

Aggregate Latency 


Data: None 

N/A 

N/A 

FPGA to RF 

Control: (l,J) 

Low (under 100 
kB/s) 

All paths must 
be deterministic and 
bounded 

(-1-10 millisecond 
is appropriate). 

RF to FPGA 

None 

N/A 

N/A 

FPGA to IF 

Data: (A) 

240 MBps 

.5 ps 

Control: None 

N/A 

N/A 


Data: (N) 

240 MBps 

.5 ps 

IF to FPGA 

Control: (H 

K), U 

Low 

All paths must be 
deterministic. Channels H 
and K must be fixed latency 

FPGA to DSP 

(D) 

36 Mbps 

Low 

DSP to FPGA 

(Q) 

36 Mbps 

Low 

FPGA to GPP 

(M) 

Low 

Low 

GPP to FPGA 

(M) 

Low 

Low 

DSP to GPP 

Data: (G) 

18 Mbps 

Low 

Control: none 

N/A 

N/A 

GPP to DSP 

Data: (S) 

18 Mbps 

Low 

Control: none 

N/A 

N/A 


The process described herein was employed during the devel¬ 
opment of Spectrum Signal Processing’s newest series of 
Software Defined Radio (SDR) products. These SDR products 
have been designed from the ground up to support tactical 
MILCOM applications; consequently, it 
was critical to validate that the modem 
architecture could support all of the JTRS 
waveforms in all of the key param¬ 
eters: processor types and capacity, 
interprocessor bandwidth and latency, and 
external connectivity. 
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FPGA memory controllers improve 
DSP performance 


By Richard M. Mathews 


Signal processors spend a significant portion of time 
and resources moving data, shuffling it in preparation for 
manipulation. This inefficiency can he significantly reduced 
for downstream DSP processors by using a large, multi-ported 
memory buffer tightly integrated with a user-programmable 
FPGA logic block and a corner-turning Direct Memory Access 
(DMA) engine. This allows DSP and other processors to spend 
a higher percentage of time and resources on intelligent data 
manipulation, reducing overhead and system complexity. 

This article examines design issues and technology advances 
that can increase efficiency and optimize performance. 

FPGAs are being increasingly used in DSP applications. They 
are especially effective at performing many kinds of repetitive 
operations and typically are combined with general-purpose pro¬ 
cessors for control operations and for data processing operations 
that require more complex decision making. 

A common I/O path bottleneck problem exists in many DSP 
systems when moving data from node to node. Another problem 
occurs when a significant fraction of processing power is utilized 
for merely shuffling data in preparation for processing instead of 
using CPU resources for actual processing. 

These data movement problems can be significantly alleviated 
by using a multi-ported memory controller that includes FPGA 
processing capabilities. Advantages include: 

■ Multiple I/O ports allow the controller to efficiently receive 
and transmit data on independent paths using the most 
practical protocol on each interlink. 

■ User Programmable Logic (UPL) within the controller can 
provide the processing power in an FPGA to offload the DSP 
processors. 

■ Large memory resources provide data buffering and 
temporary storage for intermediate results. Memory 
requirements for DSP processors can be reduced, and 
memory can be allocated to those processors in a manner 
that allows more efficient use of CPU cycles. 

■ Striding DMA that provides efficient comer turning to 
further offload processors. 

FPGA-based System-on-Chip (SoC) products are starting to 
appear on the market and include features such as the multi- 
pointed controller shown in Figure 1. 

User programmable logic and buffer memory 

Many of the data transformations performed in DSP applications 
are highly repetitive and are efficiently implemented in FPGAs. 
Fast Fourier Transforms (FFTs), convolutions, FIR filters, and 


IQ demodulation are among the processing often implemented 
in an FPGA. The parallel processing enabled by FPGA hardware 
implementations allows these operations to be performed much 
faster than using traditional processors, and the general-purpose 
or DSP processors can be offloaded to perform work that is not 
as well-suited to a hardware implementation - such as tasks that 
require decisions to be made based on the data. Fewer processors 
are thus needed in the system to complete all operations. 

The large memory on a multi-ported controller can be used in many 
ways. Input or output data can be rate buffered. An input device 
may provide bursts of data, while real-time processing proceeds 
most efficiently at a steady pace. The buffered input data can be sent 
to processing units just in time for processing. Similarly, output 
buffering may be needed if the output device is not ready imme¬ 
diately as it comes from the real-time processing system. 

The memory also may be needed between stages of 
processing. If the UPL is programmed to perform 
several independent kinds of processing such as FFTs or convolu¬ 
tions in several dimensions, large amounts of data may need to 
be stored between the stages. High bandwidth paths within the 
multi-ported controller allow the UPL to access the data several 
times without ever having to send the data over the external inter¬ 
links. The intermediate data can be stored in the buffer memory 
until enough accumulates to begin work on the next stage. Data 
sizes are application dependent and can vary significantly, from 
tens of megabytes to several gigabytes. The buffer memory also 
plays an important role in corner-turning operations. 

Many FPGAs such as the Xilinx Virtex-II Pro and the Virtex-4 FX 
include embedded processors. A multi-ported controller based on 
these FPGAs may use these processors for additional data manip¬ 
ulation. The processors can also be used for control operations 
such as programming DMA and processing exceptions. This can 
offload the other processors in the system to help them concen¬ 
trate on data manipulation and improve real-time performance. 

Corner-turning DMA 

A common problem in DSP applications is that data must 
be processed in multiple dimensions. In a 2-D image, 
for example, processing must first be performed on each 
row and then on each column of pixels. To accomplish this, the 
pixel matrix must be transposed. This is called corner turning. 

On a multiprocessor system, distributed comer turning is needed 
to accomplish the transpose across all of the processors. Each row 
processor is assigned a subset of the rows. Each column proces¬ 
sor is assigned a subset of the columns. When a row processor 
completes a row, it breaks up the row into pieces according to 
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which column processor will work on each piece. It must then 
transmit each of these pieces to all of the column processors. The 
column processors receiving a piece of a row thus get just one 
element of each column. They must wait to accumulate enough 
rows before they can begin column processing. 

This puts a large memory requirement on each column processor 
to buffer so many rows. Because each column processor must 
transpose the matrix it receives, many CPU cycles are also spent 
on corner turning. Figure 2 shows distributed corner turning, 
where data is distributed from the output of each row processor 
to every column processor by a chain of L DMA block transfers. 


Since the processors can better concentrate on data transformations, 
fewer processors are needed to accomplish all the work. The sav¬ 
ings on processors offset the cost of the multi-ported controller. 

In such an application, the first stage of processing is performed 
by the FPGA, which works on rows of data received from the 
input device. The controller uses its large buffer memory to 
save the results of transformations on many rows as can be 
seen in the striding DMA in Figure 3. After completing the 
calculations on each single row of data, internal DMA built 
into the controller transfers the results of the calculation into 
buffer memory. These rows of results are collected to form a 


By adding a striding DMA that performs matrix transposition to 
the multi-ported controller, processors can be relieved of this duty. 
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Figure 3 

matrix in buffer memory. When enough rows have accumulated 
to allow efficient column processing, each column is transmitted 
to one of many DSP processors. The column consists of just one 
element, or a small number of elements, in each row. 

The elements of the rows are stored consecutively in buffer 
memory. The consecutive elements of columns are separated in 
memory by the corresponding elements of all of the other columns, 
so they are not stored consecutively in memory. The DMA to the 
DSP processors must “stride” past all of these other columns. 
The striding DMA effectively performs a scatter-gather operation, 
collecting the nonconsecutive elements from the multi-ported 
controller’s buffer memory and transferring the elements into 
consecutive memory locations on the DSP processor. 


Any interlink can support this striding DMA. Since the data is 
sent to the DSP processors in order of consecutive memory loca¬ 
tions, it does not matter to the DSP processor or the interlink 
that the DMA engine in the multi-ported controller fetched the 
data from nonconsecutive locations in its own memory. This pro¬ 
cess implies, however, that the striding DMA must reside on the 
multi-ported controller. 

All in stride 

Figure 4 further illustrates this striding operation. The strides 
are local to the DMA master, so this is called local striding. The 
transferred segment size is the same on both the local system, the 
multi-ported controller, and the remote system. The multi-ported 
controller skips over the local stride during its access to its local 
memory. The multi-ported controller may transmit data to the 
DSP processors or receive data from them. 

Figure 5 illustrates remote striding. The multi-ported controller is 
now shown on the right, but it is still acting as the DMA master. 
It must use separate transactions to access each segment on the 
remote system. Once again, it can transmit data or receive data. 
While not as efficient as local striding since separate transactions 
must be used for each segment, this can be useful if the remote 
system is not capable of mastering its own striding DMA. 

Because the multi-ported controller buffers the data until a 
sufficient number of rows has been accumulated, the mem¬ 
ory requirement of the column processors is greatly reduced. 
In some cases without a multi-ported controller, the column 
processors are memory-limited. Compromises have to be made to 
reduce the size of the rows or columns in order to keep the matrix 
size within the limits imposed by the system. 

By using a multi-ported controller, larger rows or columns become 
practical because the column processors never have to deal with 
more than a few columns at a time. Since some operations, such 
as FFTs, require fewer instructions per pixel when performed 
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on larger columns, the CPU time needed to process the data can 
be reduced. The result is that fewer processors, each with less 
memory, will be able to complete the job. 

Real-world controller 

While FPGA processing can reduce the need for traditional DSP 
processors, a multi-ported controller tightly integrated with a UPL 


can reduce that requirement even further. Having a multi-ported 
controller reduces the memory requirements for other processors, 
and the remaining memory can be used for longer columns. This 
allows for more efficient processing. Throughput is improved by 
using the most efficient protocol on each side of the multi-ported 
controller, without sacrificing efficiency to protocol translation, 
which eats CPU cycles. 



Based on the Xilinx V-4 series of FPGAs, the CoSine SoC from 
Micro Memory combines UPL processing capabilities, a large 
multi-ported memory controller, and a striding DMA in a fully 
preconfigured solution (Figure 6). With this integrated function¬ 
ality, CoSine provides a proven design and powerful platform for 
building DSP systems. 

Richard Mathews has been at Micro Memory 
for the past three years, where he currently 
leads Software Engineering. During that time, 
he has played key roles in both hardware and 
software system architecture. Prior to joining 
the company, Richard spent nine years at Sun 
Microsystems where he was a leading member 
in the Solaris port to x86, developed a course 
for writing Solaris device drivers, and worked with Tier I OEMs 
that utilized the ChorusOS. After studying physics at Caltech, 
Richard joined Locus Computing Corp. where he specialized in 
clustering mechanisms, memory management, load balancing, 
and remote file replication. 

For more information, contact: 

Micro Memory, LLC 
9540 Vassar Ave. 

Chats worth, C A 91311 

Tel: 818-998-0070 

Fax: 818-998-4459 

Email: sales @micromemory.com 

Website: www.micromemory.com 
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Tapping into solid-state storage benefits 
for low-power and small form factor 
applications 


By Gary Drossel 


There are several advantages in using 
solid state technology in low-power and 
battery-powered applications intended 
for use in the military field. Enhanced 
security and power management features 
that are especially useful in mission- 
critical applications will be discussed, 
along with recent enhancements to solid 
state technology that have made these 
features possible. 

Due to the harsh environments in which 
they are utilized and the sensitive data 
they contain, it has long been understood 
that storage solutions used in mission- 
critical military applications require rug¬ 
gedness and advanced security beyond 
what is available in the average 2.5-inch 
rotating drive. For specialized field appli¬ 
cations including wearable computers 
and mission data recorders, solid state 
technology is currently the most effective 
storage choice, increasing the reliability 
of storage exponentially in terms of both 
environmental viability and data security. 

An evolution in solid state 
technology 

Traditionally, solid-state storage solutions 
designed to satisfy these high-capacity and 
advanced data security requirements have 
been mechanically confined to 2.5-inch 
or 3.5-inch hard drive form factors. This 
is not only because of the number of 
solid state memory components required 
to achieve the desired capacity but also 
because of the physical size of the micro¬ 
processor and associated logic used to 
provide the host system interface and the 
solid-state memory management algo¬ 
rithms. These circuits have neither been 
able to scale to smaller form factors nor 
have they been able to achieve power con¬ 
sumption less than the typical 2.5 watts 
of rotating hard drives. This makes these 
technologies impractical for battery-oper¬ 
ated or wearable computers. 

New technology has been developed that 
has broken this paradigm by using ultra-low 


power consuming proprietary Reduced 
Instruction Set Computing (RISC) tech¬ 
nology to perform the same functions 
of host interface and solid-state storage 
management. The difference, however, 
is that this technology consumes less 
than one-tenth the power of the tradi¬ 
tional solutions (0.2 watts typical) while 
achieving a mechanical footprint that 
allows traditional solid-state and rotat¬ 
ing hard drives to fit in several industry 
standard form factors such as Type I 
CompactFlash, Type II PC Cards, and 
plug-in modules. Table 1 illustrates the 
mechanical advantages of this scalability: 


the data in Figure 1 to a Flash card that can 
erase data at 10 MBps using standard ATA 
commands. The enhanced sweep technol¬ 
ogy erases the 2 GB solid-state drive in 
around 5 seconds, where it would take 
the Flash card approximately 3 minutes 
and 20 seconds to accomplish the same 
task. The advantages of this technology in 
combat situations are readily apparent. 

Data purge technology takes the sweep 
technology one step further by also eras¬ 
ing all data control blocks and, if appli¬ 
cable, the firmware that comes with 
the controller for a particular drive. 


Form Factor 

Maximum 

Capacity 

Dimensions 

Weight 

LxWxH 

2.5" Drive 

32 GB 

101 x 69.9x9.5 

> 112 g 

Plug-in Module 

4 GB 

50.8 x 5 x 22.9 

9g 

Type II PC Card 

32 GB 

85.6 x 54 x 5 

50 g 

Type 1 CF 

8 GB 

36.4 x 42.8 x 3.3 

15.2 g 

Assumes no PCB or component stacking, which can dramatically reduce reliability 
in high-shock and vibration applications. 


Table 1 


Enhanced data security 

There are several levels of enhanced data 
security required by different types of 
military applications. These levels can 
range from data sweep - also known in the 
industry as fast erase - to die-level dam¬ 
age to the nonvolatile storage components. 
When initiated by the host, usually with 
a vendor-specific command, the data 
sweep function erases all the user data in 
seconds. The solid-state storage solution 
can then be reformatted and reused. This 
is defined as a recoverable operation. 

The engineering trade-off of erase time 
versus power consumption must be con¬ 
sidered in a data sweep application as 
shown in Figure 1. The more power that 
is available from the host, the more oper¬ 
ations the controller can do in parallel, 
resulting in a faster sweep time. Contrast 


This operation is defined as being non- 
recoverable; that is, the solid state drive 
cannot be reinitialized or reformatted. 
The purge function only adds a few mil¬ 
liseconds to the data erase time and vir¬ 
tually no current, so the choice between 
implementing a sweep function or a purge 
really becomes a matter of determining 
whether or not the drive is to be used 
again. Once the drive has been purged, 
no data remains and the drive is deemed 
secure. 

Power management 

Traditional solid-state drive architectures 
can in essence be thought of as a “PC in 
a drive form factor.” These drives often 
employ a relatively high-end micropro¬ 
cessor, an FPGA for logic, solid-state 
memory components, and some type 
of RAM used as a buffer - hence the 
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Data Sweep on 2 GB Solid-State 
Storage Device 
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Figure 1 


2.5 watt power requirement and the need 
for a larger mechanical footprint and 
(relative) lack of scalability. 

The use of RAM, either DRAM or 
SRAM, as a buffer introduces the new 
design challenge of what happens to 
the integrity of the drive in the event of 
a power disturbance. RAM is a volatile 
memory architecture and if power is lost 
during a write operation, not only is the 
data lost, there is a good possibility that 
error correction and checksum of a par¬ 
ticular sector won’t match the data of that 


sector. The next time 
the controller goes to 
access that location, it 
sees the discrepancy, 
considers the sector 
bad, and may use one 
of a finite number of 
spares. If this happens 
too often, the drive 
can cease to operate 
because there are no 
spares remaining. 


Solid-state drive 
designers attempt to 
overcome this scenario 
by integrating some 
type of optional power 
holdup circuit. This 
usually involves either 
a battery backup or 
large capacitor circuit, 
which can significantly 
increase the mechani¬ 
cal dimensions of the 
drive. The circuit is 
designed to allow the 
contents of the RAM 
buffer to be properly written to the non¬ 
volatile storage components and perform 
an orderly shutdown. It is important to note 
that this does not guarantee that the file 
being written won’t be truncated. It may 
not be a useful file, but at least the drive is 
not corrupted. 

An alternative solution is to design the 
solid state drive to utilize the smallest 
buffer possible. Only the highest end of 
data recording applications truly requires 
data rates in excess of about 15 MBps, 
so other more transactional types of 



applications may be willing to sacrifice 
some speed for a high level of drive integ¬ 
rity. Additional reliability can be achieved 
by also integrating some voltage detection 
circuitry to allow the storage solution to 
make some very rapid decisions and per¬ 
form an orderly shutdown. 

The optimal solution is to integrate as 
much of this technology into the controller 
architecture itself so that mechanical foot¬ 
prints can be minimized. Figure 2 diagrams 
how a controller with voltage detection, 
regulation, and logic circuitry can be com¬ 
bined with a solid-state memory array to 
collectively maximize drive integrity. 

More solid state drives for 
military 

The application-enhancing ruggedness, 
scalability, advanced data security, and 
power management capabilities realized 
by incorporating solid state technology 
into military applications are still being 
discovered as designers replace exist¬ 
ing mechanical and magnetic drives and 
add features to new designs. These new 
features cannot, however, come at the 
expense of increased size and power 
consumption - especially in wearable or 
battery-operated field computers. 
Therefore, storage technologies tailored 
to the military market must continue to 
evolve. 

Gary Drossel is 

responsible for 
managing marketing and 
business development 
for SiliconSy stems’ 
complete product line. 

A 15-year industry veteran, he has played 
a leading role in developing the company’s 
marketing strategy, including product 
roll-out and customer introduction. 
Drossel received a BS in electrical and 
computer engineering from the University 
of Wisconsin. 

To learn more, contact Gary at: 
SiliconSystems, Inc. 

26940 Aliso Viejo Parkway 

Aliso Viejo, CA 92656 

Tel: 949-900-9400 

Fax: 949-900-9500 

E-mail: gdrossel @ siliconsystems. com 

Website: www.siliconsystems.com 
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Power Dissipation/ 
32-Channel 

12 Watts Typical"' 

35 Watts 

Phase Skew 

55ns (0,1 deg at 5KHz) 

Not specified 

Crosstalk 

96dB 

90dB 

SINAD 

93dB (PCI, cPCI,PMC, 
& PCI04+) 

86dB (cPCI), 90dB 
(PCI) 

Gain Accuracy 

+A 0.1 mV, +/- 0.1 
percent 

Not specified 

Sample Rate 

2QQK per Chan 
(PC 1 ¥ PMC t PC 104+ & 
cpci) 

108K per Chan (PCI) 
216K per Chan (cPCI) 

Industrial Temp 
Range 

-40° to me 

-40° to 85 6 C 

Commercial Temp 
Range 

0" to 65*C 

0° to 50 a C 

Cost for 
32-Channel 

$ 5,995 (Qtyir 
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Blue Chip Technology 

www.bluechiptechnology.co.uk 


. ■■'T.'Y ' 

ETX C3/C7 

ETX 

2 GHz 

Via C3 C7 



MagnumX 


2 GHz 

Via C3 C7 

Curtiss-Wright Controls Embedded Computing 

www.cwcembedded.com 


/ 






CURTISS 

WRIGHT Controls 

Embedded Computing 

Champ-AV IV 

VME 

6 GHz 

Motorola PowerPC 7447/7448 

* 

1 

CURTISS 

WRIGHT Controls 

Embedded Computing 

Manta QX3 

VME 

1 GHz 

Motorola PowerPC 7457 


1 

CURTISS 

WRIGHT Controls 

Embedded Computing 

Champ-FX 

VME 

528 MHz 

IBM 405 PowerPC 
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FPGA resources 


Ports/slots 


LU 


Other I/O 
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512 MB 


1 GB 


N/A 


IR port, audio, parallel, LCD, CRT 


Yes 


512 MB 


1 GB 


N/A 


Mini PCI, PCI, 16-channel GPIO, 
CRT, LCD, and LVDS 


Yes 


2 GB 


256 MB 


Core functionality through 
onboard timers 


Yes 


2 GB 


1 GB 


N/A 


Yes 


64 MB 


N/A 


Virtex-ll Pro 


Yes 
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Company Name/Model Number 

Form factor 

Processor speed 

(Fastest available) 

Processor manufacturer & model 

Danville Signal Processing, Inc. 

www.danvillesignal.com 


O Danville Signal 

dspstak DSP boards 


400 MHz 

Analog Devices SHARC 

Hunt Engineering 

www.hunt-dsp.com 



HERON-USB-18 


400 MHz 

Xilinx Power PC and Tl C6000 

Intel Corporation 

www.intel.com 


Intel 

MPCBL0001 

PMC 

2 GHz 

Intel MPCBL0001 


Intel 

MPCBL0010 

ATCA 

2.8 GHz 

Intel MPCBL0010 

Tews Technologies 

www.tews.com 


TEWS^- 

TECHNOLOGIES 

TVME8240 

VME 

250 MHz 

Motorola MPC8240 

B 

TEWS^ 

TECHNOLOGIES 

TVME8300 

VME 

300 MHz 

Motorola MPC8245 
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Max volatile memory 

Max nonvolatile memory 

FPGA resources 

Ports/slots 

Conduction cooling available 

Ethernet 

Mezzanine 

SCSI 

Serial 

USB 

Other I/O 


8 MB 

512 KB 

Altera Cyclone FPGA available 
on some boards 

0 

4 

0 

1 

2 

SPI, I/O expansion port, JTAG, 
built-in ICE (USB) 

No 


288 MB 

16 MB 

Virtex-4 FX12, LX60/SX35 Virtex-ll and 

0 

4 

0 

3 

1 

210 Mhz ADC, 160 Mhz DAC, LVDS/LVTTL, 

No 



Virtex-ll Pro 






FPDP, camera link 



4 GB 

266 MB 

N/A 

2 

1 

1 

1 

1 

Dual Gigabit Ethernet, optional dual Fibre 
Channel 

Yes 

4 GB 

1 MB 

N/A 

2 

1 

1 

0 

1 

Dual GB Ethernet base and fabric interface 

Yes 


64 MB 

8 MB 

Optional IP FPGA mezzanine 

1 

4 

1 

2 

0 

Four industry pack sites 

No 

64 MB 

8 MB 

Optional PMC or IP FPGA mezzanine 

1 

4 

1 

2 

0 

Optional IP or PMC expansion 

No 
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Company Name/Model Number 

Form factor 

Processor speed 

(Fastest available) 

Processor manufacturer & model 

ES ! 1 

M 


TEWS& 

TECHNOLOGIES 

TVME8400 

VME 

300 MHz 

Motorola MPC8245 

Thales Computers 

www.thalescomputers.com 



THALES 

PowerEngine7 

VME 

1 GHz 

IBM PPC 750GX 


VMETRO Inc. 

www.vmetro.com 

i 


UP1ETRO 

innovation stepipjed 

PowerMIDAS C5000 

CompactPCI 

800 MHz 

AMCC PPC440GX 


UfllETRO 

innovation stepipjed 

PowerMIDAS M5000 

VME 

667 MHz 

AMCC PPC440GX 


UPIETRO 

innovation deployed 

VPF1 

VME 

1.25 GHz 

Freescale 7447A 

1. Data is from the OpenSystems Publishing online database as of presstime. Vendors are encouraged to update and add listings to our online database. 

To update, see www.opensystems-publishing.com/vendors/submissions/np/. 

2. Entries have been edited per OpenSystems Publishing standards and are listed at the sole discretion of the editor. OSP offers no warranties, accepts 
no liability, nor offers indemnification from omissions or errors. 
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Product Selection Guide 


Max volatile memory 

Max nonvolatile memory 

FPGA resources 

Ports/slots 

Conduction cooling available 

Ethernet 

Mezzanine 

SCSI 

Serial 

USB 

Other I/O 

64 MB 

8 MB 

Optional PMC FPGA mezzanine 

1 

2 

1 

2 

0 

Dual PMC sites 

No 


512 MB 

128 KB 

N/A 

2 

2 

1 

6 

1 


Yes 


1 GB 

32 MB 

N/A 

2 

2 

1 

2 

1 

Up to 2 x 2 Gbps optical fiber and PIM 

No 

256 MB 

32 MB 

N/A 

3 

2 

1 

0 

1 

2x2 Gbps optical fiber, RS-232/422, RACE++ 

No 

512 MB 

128 MB 

2 V2Pro P70 FPGAs with dedicated QDR 
SRAM and SDRAM 

2 

1 

1 

4 

1 

Rocket I/O, direct FPGA 

Yes 


To view the full product selection guide, go to 
www.mil-embedded.com/products/guides/reconfigurableSBCs 
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CARRIER BOARD: PMC 


N.A.T. GmbH 

Website: www.nateurope.com 

Model: NcPCI-PMC RSC No: 21630 



PCI interface and compliance: Intel i21555 PCI-to- 
PCI bridge (66 MHz, 64-bit), PCI Rev. 2.2 • H.110 
bus: Agere T8110 TSI, H.110 on CompactPCI 
J4 connector, SCbus on PMC P14 connector • 
PMC slots: two 64-bit/66 MHz PCI Rev.2.2 IEEE 
PI 386.1/Draft 2.4a compliant PMC slots on the 
PCI internal bus, I/O PI4 connector used as SCSA 
bus connected to the T8110 TSI H.110 device • 
Full hot swap capability • Power consumption: 
3.3 V, 0.5 A (typical), 5 V, 0.1 A (typical) • 0 °C to 
+60 °C operating temperature range, with forced 
air cooling • Standard compliance: PCI Rev. 2.2, 
PICMG 2.1 R2.0, PICMG 2.5 R1.0, IEEE P1386.1/ 
Draft 2.4a 


By Sharon Schnakenburg 


CHIPS & CORES: FPGA 

DATA ACQUISITION 

SBS Technologies, Inc. 

Website: www.sbs.com 

Model: TS-CPCI-8001 RSC No: 21058 


Great River Technology, Inc. 

Website: www.greatrivertech.com 

Model: Gravity 64/32 HOTIink II Data RSC No: 21376 


* 



High-performance, FPGA-based computing plat¬ 
form for demanding signal and image processing 
applications • Suitable for SDR, sonar, and other 
high-performance signal processing applications 
• Dual Stratix EP1S80 FPGAs onboard • Two PMC 
sites with 1 GBps high-speed data paths to each 
FPGA • 8 GBps connection between FPGAs for a 
common processor fabric • Windows XP/2000, 
Linux, and Integrity software support 



Military-style connector solutions available with 
fiberoptic MIL-T-19504 approved termini, coupled 
with COTS cabling and fiber optic connectors 
• Suitable for a variety of military, avionics, flight 
control, mobile tactical field command platforms, 
EMI-sensitive, and security applications • Utilizes 
ruggedized connectors designed for harsh envi¬ 
ronments • Various finish types offered with plug, 
jam-nut, and wall-mount receptacle options • Can 
be terminated to both single-fiber and ribbon cable, 
available in 2- to 29-pin configurations to meet 
MIL-STD-1560 requirements •Custom lengths for 
COTS cabling and fiber routing options 


Flexible, off-the-shelf solutions for high-speed, 
point-to-point data transfer using HOTLink II Fibre 
Channel • Supports baud rates from 200 Mbps to 
1.5 GBps • Variety of uses includes engineering 
development and factory test of HOTLink based 
interfaces • Can be used with almost any customer- 
defined HOTLink protocol, with data rates of 160 
Mbps to 1.5 GBps • Flexible connector options 
• Fiber option single or dual channel, FCN single or 
dual channel, or SMA • Flexible protocols • Users 
can select one of three modes: 4 byte packets, 
variable length packets, or fixed length packets 


DSP RESOURCE BOARDS: PCI-X 


Signatec,Inc. 

Website: www.signatec.com 

Model: PMP1000 RSC No: 21253 



Parallel DSP Board • 72 GIPS peak processing 
power • Continuous input data processing up to 
1000 MBps (depending on application) • Up to 
nine Tl C6414 DSPs • 64 MB memory in each 
of eight main processing DSPs, totaling more 
than 512 MB DSP memory • Unique program 
execution processor for dynamic thread alloca¬ 
tion • Advanced parallel DSP OS simplifies user 
programming • Customizable external interface 
for accommodating any type of user data chan¬ 
nels • 2.5 GBps of total external I/O via three 
interfaces • 2600 MBps internal I/O via switching 
network • 64-bit PCI-X local bus full-length board 
• Designed to create true high-speed, real-time 
systems in otherwise non-real-time environments 
(such as PCs) 
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We’ve got your back. 
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Ground Force Systems Specialists and 
communications experts must think clearly under 
fire, and respond with lightning speed. The 
rigorous physical and mental challenges of combat 
demand field equipment built to ensure mission 
success because the data captured, analyzed and 
transmitted helps make split-second decisions that 
save lives. 

It's no wonder so many manufacturers choose 
Ampro SBCs and modules for rugged embedded 
applications. Ampro has always been the leader in 
modular embedded technology. And with their 
recent deployment of the first rugged ETX module, 
Ampro continues to out-rank all others in the field. 


Because more than your reputation is at stake. 


Call today (408) 360-0200 or visit: www.ampro.com/RuqqedETX 



Ampro is a registered trademark of Ampro Computers, Inc. All other trademarks are the property of their respective owners. © 2005 Ampro Computers, Inc. All rights reserved. 
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DSP RESOURCE BOARDS: PCI/ISA 


Innovative Integration 

Website: www.innovative-dsp.com 

Model: M6713 RSC No: 21886 



DSP + FPGA board with novel architecture for 
advanced data capture and real-time control in PCI 
systems • Designed around Texas Instruments’ 
floating-point DSP for high-speed, high dynamic 
range signal processing, and Xilinx’s latest FPGA 
for unlimited customization of I/O peripherals • 
PCI 64-bit/66 MHz • Two OMNIBUS I/O module 
sites • Reconfigurable FPGA option up to 1.5 mil¬ 
lion gates • Supports multiple card I/O synchroni¬ 
zation • Extensive software support in source form 
• Custom logic development supported for FPGA 


DSP RESOURCE BOARDS: PMC 



XC2VP50 Xilinx Virtex-ll Pro FPGA PMC supporting 
two or four fiber optic I/O channels, each of which 
connects to a RocketIO channel on the FPGA • 
64-bit user programmable data port (PMC user 
I/O PI4) • Two banks DDR SDRAM (64 MB per 
bank) • Three banks QDR-II SRAM (up to 8 M x 
18-bit per bank) • 2 or 4x fiber-optic transceivers 
(front panel) • Bandwidths of up to 3.125 GBps 
per port • 64-bit user programmable data port 
(PMC user I/O PI4) • 4 MB Flash memory 


FABRICS: FIBRE CHANNEL 


Data Device Corp. (DDC) 

Website: www.ddc-web.com 

Model: FibreAccess RSC No: 21225 



Based on DDC-developed Intellectual Property, 
enabling long life cycle support and customizability 
for military applications • Dual-channel operation • 
True conduction cooled, flyable design at temper¬ 
atures -40 °C to +85 °C and beyond • 1 or 2 GBps 
operation • Class 2 and 3 service including broad¬ 
cast and multicast • 320 MBps throughput with 
memory-to-memory latency under 20 pS • Proven 
interoperability with both avionics-only and com¬ 
mercial fibre channel cards and switches • Rugged 
low-profile transceiver option offers approximately 
50% of the footprint of a standard small form fac¬ 
tor optical transceiver, enabling military/aerospace 
customers to minimize overall size and weight and 
to increase fiber optic cable bend radius 


FABRICS: PICMG 2.16 ETHERNET 


DSS Networks 

Website: www.dssnetworks.com 

Model: Metro-Switch Model 8261 RSC No: 21049 



12-port PIGMG 2.16/VITA 31.1 6U gigabit switch 
fabric card • Unmanaged, lightly managed, or 
fully managed modes • Rugged versions avail¬ 
able with extended temperature and conformal 
coating features for harsh environments • 850 
nm multimode, 1310 nm single mode, and WDM 
fiber connector options • Simultaneous, fully 
independent operation on all ports, 32 Mbps- 
24 GBps • Fourth generation BCM5690/5695 
switch fabric and BCM5464SRKB quad port 
transceivers from Broadcom • High-perfor¬ 
mance wire speed on all ports, 24 GB aggregate 
total, 1 MB onboard memory for packet buffer¬ 
ing • Fully compliant to IEEE 802.3 specifications 
including auto negotiation • Available with OEM 
developer kit • VxWorks and Linux driver support 


GENERATORS: FUNCTION/WAVEFORM 


ZTEC Instruments, Inc. 

Website: www.ztec-inc.com 

Model: ZT530PCI RSC No: 20700 



A three-in-one modular instrument that provides a 
high-performance arbitrary waveform generator, a 
function generator with built-in waveforms, and a 
high-speed digital pattern generator • Paired ana¬ 
log signals with minimal channel-to-channel skew 
provide high-quality differential or IQ signal gen¬ 
eration • Digital TTL outputs provide time mark¬ 
ers, sync, or pattern stimulus • Instrument control 
achieved through command interface or register 
level access • Two channels simultaneous, 16-bit 
resolution • 160 MSps data rate with 2x, 4x, and 
8x interpolation filter for up to 400 MSps • Up to 
2 MS record length per channel • 32 TTL pattern 
outputs • Differential waveform synthesis 


MIL-STD-1553 


Ballard Technology 

Website: www.ballardtech.com 

Model: OmniBus Family RSC No: 20634 



Mixed protocols • High channel counts • User pro¬ 
cessor (PowerPC) • IRIG time and synchronization 
• Features one to four DSPs for protocol process¬ 
ing • Supports MIL-STD-1553, ARINC 429, ARINC 
708, ARINC 717, serial ports (RS-422/232/423), 
CSDB, discrete I/O, and more • Available in several 
platforms (PCI, cPCI, VME, and USB/Ethernet) • 
Commercial temperature standard, industrial avail¬ 
able • Modular design supports mixed-protocol 
applications • Can be upgraded/reconfigured 
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BMC Communications 

Website: www.bmccorp.com 

Model: PCI-UADI RSC No: 21267 





PROCESSOR: POWERPC 


Creative Electronic Systems 
Website: www.ces.ch 

Model: RIOC 4070 RSC No: 21125 



Conduction-cooled PowerPC 750Gx at maximum 
frequency • 512 MB global memory SDRAM at 
800 MBps peak • CES-enhanced PowerPC-to- 
CompactPCI bridge • 16 independent linked list 
DMA channel engine • Two onboard PMC slots • 
Power-on/power-off control logic per PMC slot • 
High throughput DMA engine • 32 MB NOR with 
compressor • 256 MB NAND with high-speed file 
system • Multiple thermal sensors • Transparent 
multiprocessor extension with up to six MFCC 
8446 companion modules • Extended BSPs for 
VxWorks 6.x and Integrity 5.x 


A PCI universal avionics digital interface • 16-bit 
RISC low-power microcontroller that allows firm¬ 
ware programming in the field through a com¬ 
puter • Supports many communication protocols: 
MlL-STD-1553 dual redundant interface, ARINC 
708/453, ARINC two-wire/six-wire protocols such 
as 429/575/571/572/581/582/615, and RS-232 

• Error injection/detection • 32-bit message time 
tagging • Extensive BC and RT link list structures 

• Automatic/manual RT status bit • Advanced BC 
functionality • Onboard built-in test bus and hard¬ 
wired RT access • Fully compatible with the tem¬ 
perature, humidity, and vibration standards of MIL- 
STD-810E and EMI MIL-STD-416 • C Libraries, 
DLLs, Windows, and Linux device drivers 



Andor Design Corp 

Website: www.andordesign.com 

Model: PC401 RSC No: 22183 


PCMCIfl/PC CARD 


PCMCIA Type 2 to MIL-STD-1553 • Simultaneous 
BC, multiple RTs monitor • 16/32 bit time tag • 
Auto incrementing 128 k X16 dual port static RAM 
Interface • Full error detection and generation • 
Onboard major minor frame timing • Program 
selectable protocol, A, B, custom • Programmable 
message parameters • Programmable output 
amplitude • Full/selective bus monitor • Full bus 
simulation/support validation/production test plans 
• One application for ISA, PCI, PCMCIA • Support 
for multiple assorted cards on the same platform 




Looking for Solutions to the 
RFID Equation? 


PowerPC Computing Engine + Linux + PCMCIA RFID Reader 



Quality is designed into every Embedded Planet product. Each product is 
designed to take you from prototype through production quantity volumes. 


Superior Documentation ensures that you are up and running shortly after you 
open the box. Visit our web site to download our documentation. 

Our engineers can Support your project with both hardware and software 
experise to help you meet your time and budget constraints. 


We can customize any of our modules for your application. 
Visit our website or contact us today for your 
complete solution. 

4760 Richmond Rd / Cleveland, OH 44128 
Tel: 216.245.4180 /Fax: 216.292.0561 
www.embeddedplanet.com 
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TURNKEY SYSTEM 


Lanner Electronics, Inc. 

Website: www.lannerinc.com 

Model: EM-S300A RSC No: 19111 



Intel ULV Celeron CPU-based, wall-mountable 
mini workstation • Rugged construction for harsh 
environments • 10/1 OOBase-T and AC’97 audio • 
Two COM ports, one parallel port, four USB ports, 
and one IrDA • Reserved CompactFlash Type I/ll 
socket • One 2.5" HDD bay • Intel ultra-low-volt- 
age Celeron processor at 650 MHz or 400 MHz 
(fanless) onboard • VIA chipset integrated with 
AGP 4X graphics • Supports 36 bits TFT/DSTN/ 
STN LCD and two channels (2x18 bits) LVDS • 
One ATA/100 IDE channel • One built-in PC/104 
expansion slot 


VIDEO: FRAME GRABBER 


ARVOO Imaging Products BV 
Website: www.arvoo.com 
Model: leonardo PMC64-CL RSC No: 20721 



PMC mezzanine video processor for CameraLink 
Base (24-bit) digital video • Onboard FPGA (Xilinx 
Virtex E 100/300) for preprocessing of acquired 
video data offers contrast stretching in gray value 
domain, RGB mosaic color restoration, and ran¬ 
dom 2D convolution filters • Onboard memory of 
128 MB • PMC bus interface 64-bit/66 MHz maxi¬ 
mum, resulting in an extreme transfer rate of 528 
MBps • Software support for Windows, Linux, 
Real-Time Linux, QNX, and Solaris • Digital I/O 
lines available 



When failure just isn't an option 
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Hybricon performs 

Hybricon Corporation is,i world-class leader in the design 
and manufacture of electronic packaging solutions for high 
performance military and luggedized COTS application*. 
Hybricon has a successful track record of proven and depleted 
CUTS mlui ions iliat have been designed in meet slfingenl 
military requirements. 

Call us ar 1^877 HYBRICON 149 2-74I&} nr visit 

ivTrtM.hvbrLcon.com 


Hybricon® 

Anwittldan * Quilttr * gantim 


HybriDon Corporplion 15 Willow Ftood 
Ayer, MA01432 ISO 9001 Certified 


www*hybricon*com 
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The cost of failing to deploy SDRs is well-documented. The 
war game Operation Atlas showed that only United Airlines 
and the FBI could communicate with the “hijacked” air¬ 
plane via the traditional Aircraft Communications Addressing 
and Reporting System (ACARS). But officials participating 
in the exercise from Massachusetts’ Massport, state police, 
Federal Air Marshal Service, Homeland Security, Coast Guard, 
FAA, and others could only wait for information to trickle in. 
A key failure noted at the end of the exercise: Information sharing 
and direct communications between agencies is lacking. 


R ecent worldwide events have shown that we can no 
longer wait for Software Defined Radios (SDRs) in 
military and civilian applications. For once, the obsta¬ 
cle is neither perception nor technology - it’s simply a 
matter of money. And not that much money, since COTS equip¬ 
ment already exists. World events like last year’s Indian Ocean 
tsunami, hurricanes Katrina and Rita in the United States, and 
the recent earthquake in Afghanistan’s Muzaffarabad region and 
neighboring Pakistan all point to the need for interoperable com¬ 
munications equipment and infrastructure. 


In emergency and chaotic situations, using portable wireless radio 
equipment is by far the most efficient way to communicate when 
disasters or terrorism wipe out land-based systems. Though robust, 
battery-backed up Plain Old Telephone Service (POTS) and cel¬ 
lular phone basestations are in fixed and often vulnerable areas 
subject to floods, earthquakes, or terrorism. 

On June 4, Operation Atlas was the first airborne counterterror¬ 
ism “war game” drill in the United States since 9/11. Nearly four 
months later, hurricanes Katrina and Rita struck. Both the Atlas 
exercise and the hurricanes uncovered critical and deadly weak¬ 
nesses in the communications abilities of first responder civil¬ 
ian and military personnel. In short: Inadequate infrastructure, 
planning, and radios that don’t talk between organizations lead to 
simulated - as well as actual - life and death situations. 

Articles published in this issue of Military Embedded Systems 
by industry experts such as Spectrum Signal Processing, General 
Dynamics C4 Systems, Composable Logic, and SCA Technica 
(page 28) all define SDR as digital radios that can create multiple 
waveforms to enable interoperability between legacy radios. SDR 
has grown into the basis for the DoD’s massive Joint Tactical 
Radio System (JTRS) program that seeks to bridge communi¬ 
cations between dozens of legacy military radios and ultimately 
replace them. 

The technology exists today, and JTRS progress remains 
strong with tens of billions of dollars in congressional funding 
($12-15 billion, according to my estimates, Boeing, and Xilinx). 
But the commercial and civilian worlds, including police, fire, 
city, and state officials, FEMA, and the Red Cross, lag far behind 
with outdated and RF communications that generally can’t talk to 
each other, much less to the military such as the National Guard 
troops who eventually descended upon New Orleans. The funda¬ 
mental technologies needed for SDR include low-power proces¬ 
sors such as those from ARM used in cell phones, DSPs from 
companies like TI and Analog Devices, and partially reconfigu- 
rable FPGAs from the likes of Altera, Xilinx, and others. The 
software “middleware” called the SCA that’s necessary to make 
it work has been developed by the DoD and is available from 
various sources and administered by the Software Defined Radio 
Forum (SDRF). 


So, too, were the lessons from Hurricane Katrina. Do a Google 
search on “Katrina interoperable communications” and 33,500 
hits are returned. With everything under water, only walkie-talk¬ 
ies and a few police networks survived. In one instance, FedEx 
noticed that one of their own radio antennas atop a 54-story 
building had survived. FedEx technicians and the Army’s 82 nd 
Airborne rigged a generator to the transceiver and distributed 
125 walkie-talkies to emergency responders. Cell phone compa¬ 
nies deployed portable base stations to replace damaged towers. 
The myriad agencies involved in disaster relief not only had no 
communications infrastructure, they couldn’t have talked to each 
other even if they did. 

SDR pioneers such as Vanu already sell and have deployed COTS 
systems such as the Any wave Base Station that can realize mul¬ 
tiple cell phone protocols so that one basestation can talk to all 
major carriers via GSM, CDMA, WCDMA, and so on. The prod¬ 
uct is being tested at the Idaho National Laboratory. Vanu has an 
SDR version that mounts in a first responder’s vehicle that can be 
programmed to bridge police frequencies with fire and other offi¬ 
cials, allowing different radios to interoperate. And the equipment 
is based on low-cost Pentium processors and FPGAs. 

Clearly the issue isn’t lack of demand or technology. Congress 
recognizes that interoperability failures demand “immediate 
action.” A report written by senators McCain (AZ) and Lieberman 
(CT) and representatives Harman (CA) and Weldon (PA) pub¬ 
lished in the Washington Post on 9/18 indicates we’re no better 
off four years after 9/11, and that “Policymakers at all levels have 
failed...by not taking action on interoperability.” The very next 
day, the Senate failed to agree on waiving budget rules that would 
provide funding for interoperable communications equipment. 
The bill failed 40-58. 

As I write this, Hurricane Wilma is at Category 5 and is bearing 
down on Florida. Can we afford to wait another four years for 
SDR’s promise of interoperable communications? 



Group Editorial Director 
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Extreme Engineering Solutions 

Website: www.xes-inc.com 

Model: XCaliburl002 RSC No: 22443 



A 6U CompactPCI ruggedized, extended tem¬ 
perature blade • IBM 750GX PowerPC processor • 
Ruggedized and operational from -40 °C to +85 °C 
• Dual PCI-X PrPMC slots • Up to 1 GB 266 MHz 
DDR SDRAM • 4-80 MB soldered Flash and 
CompactFlash socket • Dual PCI-X PrPMC slots • 
Front panel serial and 10/100/1000 Mbps Ethernet 
ports • Two 10/100/1000 Mbps PICMG 2.16 back¬ 
plane Ethernet ports • Complies with PICMG 2.0, 
2.1, 2.3, 2.9, 2.16 • VxWorks, Linux, and QNX 
Neutrino V6.3 support 


ROUTERS/SWITCHES 


ACT/Technico 

Website: www.acttechnico.com 

Model: 6U GigE Switch RSC No: 22362 



24 10/100/1 OOOBase-T Ethernet ports • Switching 
capacity of 24 M packets (16 ports) and 36 M pack¬ 
ets (24 ports) • Full-line rate switching engine • 
8,000 MAC addresses • Port and MAC access con¬ 
trol • Flow control and back pressure • Automatic 
or controlled learning and aging routing table • 
Link aggregation/port trunking • Jumbo frame of 
up to 10 KB • 256 active VLANS • Enhanced port 
mirroring • STP/RSTP algorithm for more reliable 
network communications • Four priority queues 
per port • Easy software updating via FTP down¬ 
load to local in Flash memory • Comprehensive 
power on built-in test • Thermal monitoring 
• Extended temp and rugged versions available 


SERVER 


NextCom 

Website: www.nextcomputing.com 

Model: Flextreme RSC No: 22828 



A briefcase-sized portable server and mobile work¬ 
station • Open standards architecture • Processor 
configurations: single, dual, or dual-core Opteron 
processors • Multiple high-performance memory 
configurations • Multiple Gigabit Ethernet ports • 
Multiple SATA and USB 2.0 ports • PCI Express 
XI6 expansion slot • Optional Ultral60 SCSI 
or fibre channel • Dual head graphics support • 
Multiple removable or fixed HDD configurations 
• Supports several operating systems: Linux, 
Microsoft Windows 2003 Server, XP Pro, 2000 
Pro, Solaris x86, Trusted Solaris x86, Solaris 10, 
Win-UX concurrent use Linux and Windows, and 
multiple dual boot environments 


SOFTWARE-DEFINED RADIO 


Interactive Circuits & Systems Ltd. (ICS) 

Website: www.ics-ltd.com 

Model: PMC571 RSC No: 21093 





4 million gate FPGA, providing the platform for 
application-specific software development within a 
XilinxVirtex II environment •Single-channel, soft¬ 
ware radio rugged mezzanine • Sample rates up to 
80 MHz and processing bandwidth of 40 MHz • 
14-bit data conversion on ADC and DAC functions 
• Full 64-bit, 66 MHz PCI interface and a 64-bit 
general-purpose I/O • PCI 2.2 compliant (64-bit, 
66 MHz), Master/Target Burst Mode (DMA) capa¬ 
ble, with DMA chaining (scatter-gather) • Keyed 
for universal signaling • Sampling/conversion 
occurs following rising or falling edge of external 
trigger (programmable) • Air- and conduction- 
cooled ruggedization levels and extensive applica¬ 
tion and technical support data available 


Spectrum Signal Processing 

Website: www.spectrumsignal.com 

Model: SDR-3000 RSC No: 22214 



Software-Defined Radio platform • CompactPCI- 
based architecture • Xilinx Virtex-ll FPGAs 

• PowerPC MPC7410 G4s • Optional Tl 
TMS320C64X DSPs • Supports IF sampling rates 
up to 212 MHz • Supports 2-4 ADC channels and 
2-4 DAC channels per slot • FlexFabric - serial rapid 
IO-based switched fabric connects all boards with 
deterministic, low-latency 320 MBps data paths 

• Supports up to 1,000 simultaneous transmit and 
receive communication channels per chassis • 
Includes optional SCA core framework • Supplied 
with full CORBA support (TAO) • Supports the 
VxWorks RTOS on every PowerPC node 


SOFTWARE: MODELING TOOL 


Zeligsoft 

Website: www.zeligsoft.com 

Model: Component Enabler RSC No: 20776 



Creates visual models of SDR systems that 
adhere to the SCA standard as defined by the 
JTRS • Validates the models for compliance to the 
SCA standard • Generates correct-by-construc- 
tion XML descriptor files and user-customizable 
documentation • Imports existing or third-party 
descriptor files, validates for standards compli¬ 
ance, visualizes, and integrates into a full system • 
Provides development team with a UML 2.0-based 
visual representation of system architecture • 
Provides early validation and generation of SCA 
2.2, 2.2.1, and 3.0 compliant descriptor files 
• Improves overall quality and readability of 
waveform applications • Fits within current devel¬ 
opment processes 
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Battle Grade Ethernet™ 



SBS knows rugged Ethernet. With failover and BIT, our switches are battle ready. 


OUR GIGABIT ETHERNET SWITCHES have been through 
boot camp—they've been tested, qualified, 
toughened up and generally put through the 
wringer. What emerges from this brutal test 
of character is Battle Grade Ethernet™. 


These switches come with failover software 
and built in test (BIT). They are available in air or 
conduction cooled versions, with up to 24 ports 
for 6U or 3U CompactPCI® systems. Our most 
rugged switches can operate at temperatures 
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from -40° to +85° C and have been designed to 
meet VITA 47 classes ECC1, ECC2, ECC3 
and ECC4. 


Ethernet is a proven technology in many 
military programs, and it is an important 
element of most networking applications. Which 
means Ethernet will have the kind of long term 
support that is critical in COTS programs. So if 
you're looking for Ethernet that has earned its 
stripes, give us a call. Sir. 



Technologies. 


SBS knouis. 

Find the Ethernet you’re looking for at ujujui.defense.sbs.com or call 800.SBS.EMDEDDED 
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